Excerpts from Amit Saha's message of 2013-11-19 12:23:56 +1000:
Do we want to link to the tarball from the releases page? I believe
so. The problem here is (AFAICT) that we don't get the tarball
filename until we tag it. Hence, I can't see how it can be done at the
time of tagging. If tito had a --dry-run option for tagging that would
be easy. I opened an issue with the project and have a patched version
which works [1].
Well the tag which tito uses is not an inscrutable mystery :-) it is
easily predictable (and indeed, you should know what version you are
tagging *before* you tag it). It's going to be either x.y.z+1 if you let
tito do the bumping, or else you bump it manually to whatever version
you want and then use tito tag --keep-version to commit it.
Here is what I have without involving GitHub in any way:
# tito tag --dry-run
# add changelog and archive download link
git add documentation/release-notes.rst
# tito tag
# git push tag
# create the .tar.gz
release_tag=`git tag --points-at HEAD`
git archive --format=tar.gz --prefix=$release_tag/ $release_tag >$release_tag.tar.gz
# upload it to
beaker-project.org/releases
scp $release_tag.tar.gz beaker-project.org:/path-to-releases/
(I see that releases is in .gitignore, so I believe it should be fine?)
All the content on
beaker-project.org needs to be tracked in git on the
published branch. That lets us track and preview what will be published,
and also gives us a backup (there are no full-disk backups for
beaker-project.org). So scp'ing random stuff into the webroot defeats
all that.
The tarballs should either be generated automatically during the web
site build (like the ones for beaker are) or else committed to the web
site source tree (this would be annoying because it's a lot more
shuffling).
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.