No edit summary |
|||
(4 intermediate revisions by 2 users not shown) | |||
Line 46: | Line 46: | ||
# Check that the tag was applied to the correct commit by inspecting: <pre>git log --decorate=full</pre> | # Check that the tag was applied to the correct commit by inspecting: <pre>git log --decorate=full</pre> | ||
== | == Pull changes back to master == | ||
After you tag the release on the release branch, you | After you tag the release on the release branch, you need to pull the release-related changes (now tagged with ''vX.Y.Z'' tag) into the master branch. Merging is a preferred approach, because it ensures the master branch will contain the ''vX.Y.Z'' commit. But it is desirable only for a fast-forward merge, otherwise some other changes (we might not want) may be pulled in as well. In that case (e.g. the release branch was used for stabilization and contain several previous commits) we need to use cherry-picking. | ||
# Change to the ''master'' branch <pre>git checkout master</pre> | # Change to the ''master'' branch <pre>git checkout master</pre> | ||
# | # If you created the release branch immediately before tagging a new release, merge the changes using fast-forward approach: <pre>git merge --ff-only release-X.Y</pre> | ||
# If you can't use fast-forward merge or it failed, cherry pick the appropriate commit instead: <pre>git cherry-pick vX.Y.Z</pre> | |||
== Push changes to remote repository == | == Push changes to remote repository == | ||
Line 85: | Line 86: | ||
}} | }} | ||
# Build packages using mock for Fedora, specify version using <code>DIST</code> variable. For possible values for <code>DIST</code>, consult [[Packaging:DistTag]] {{#tag:pre|make | # Build packages using mock for Fedora, specify version using <code>DIST</code> variable. For possible values for <code>DIST</code>, consult [[Packaging:DistTag]] {{#tag:pre|make mock DIST=.fc{{FedoraVersionNumber|current}} }} | ||
# Repeat the build procedure for all desired releases | # Repeat the build procedure for all desired releases | ||
Line 93: | Line 94: | ||
<ol> | <ol> | ||
<li> Mirror the autoqa package repository locally <pre>rsync -avz fedorapeople.org:/srv/repos/fedora-qa/autoqa ~/public_html/ ; cd autoqa/</pre></li> | <li> Mirror the autoqa package repository locally <pre>rsync -avz fedorapeople.org:/srv/repos/fedora-qa/autoqa ~/public_html/ ; cd autoqa/</pre></li> | ||
<li> Add locally built packages to the desired repositories <pre>./move-pkgs.sh path/to/autoqa.git/ | <li> Add locally built packages to the desired repositories <pre>./move-pkgs.sh path/to/autoqa.git/build/MOCK/*/*.rpm</pre> | ||
{{admon/note|Simulating the ''updates-testing'' repository|For pre-release or testing packages an alternative repository is available to mimic the official ''updates-testing'' Fedora repository. To submit packages into the ''fedora-autoqa-testing'' repository, add the command-line option <code>-r testing</code>. A complete example is included below. | {{admon/note|Simulating the ''updates-testing'' repository|For pre-release or testing packages an alternative repository is available to mimic the official ''updates-testing'' Fedora repository. To submit packages into the ''fedora-autoqa-testing'' repository, add the command-line option <code>-r testing</code>. A complete example is included below. | ||
<pre>./move-pkgs.sh -r testing path/to/autoqa.git/ | <pre>./move-pkgs.sh -r testing path/to/autoqa.git/build/MOCK/*/*.rpm</pre> | ||
}}</li> | }}</li> | ||
<li> Update the yum repo metadata <pre>./update-repos.sh</pre></li> | <li> Update the yum repo metadata <pre>./update-repos.sh</pre></li> | ||
Line 127: | Line 128: | ||
# SSH to the staging server and go to the AutoQA checkout directory (create one if you don't have one). | # SSH to the staging server and go to the AutoQA checkout directory (create one if you don't have one). | ||
# Switch to the git branch you want to test, probably ''master'': <pre>git pull; git checkout master</pre> | # Switch to the git branch you want to test, probably ''master'': <pre>git pull; git checkout master</pre> | ||
# Build an RPM from current ''HEAD'' using the same approach as in [[#Build for applicable releases]], but with appending <code>DEVEL=1</code> option: <pre>make | # Build an RPM from current ''HEAD'' using the same approach as in [[#Build for applicable releases]], but with appending <code>DEVEL=1</code> option: <pre>make mock DEVEL=1</pre> | ||
#* Your user must be in the ''mock'' group to be able to run this. | #* Your user must be in the ''mock'' group to be able to run this. | ||
# Install the RPM created in {{filename|./build/MOCK/<release>/}}. | # Install the RPM created in {{filename|./build/MOCK/<release>/}}. | ||
#* Be sure to inspect all {{filename|.rpmnew}} and {{filename|.rpmold}} files and merge the changes. | #* Since we use <code>git describe</code> to generate package versions and sometimes we build and install package from other branches than master, you can actually end up with a package version that is lower than the one currently installed. Instead of using <code>yum update autoqa-version.rpm</code> use <code>yum downgrade autoqa-version.rpm</code>. | ||
#* Be sure to inspect all {{filename|.rpmnew}} and {{filename|.rpmold}} files (if they are created, yum will tell you so) and merge the changes. | |||
[[Category:AutoQA]] | [[Category:AutoQA]] |
Revision as of 10:14, 16 March 2012
This page describes the process for tagging, building and deploying a new version of autoqa. This page assumes a basic understanding of rpm spec
file syntax and commands such as git
, mock
and yum
.
Numbering scheme
Each release has X.Y.Z identification denoting a major, a minor and a revision number:
- Major number is increased when AutoQA makes incompatible changes in its test API. (Not used currently, since no stable public API has been offered yet.)
- Minor number is increased when AutoQA adds new features.
- Revision number is increased when AutoQA adds new hotfixes, but no new features.
Pre-requisites
You must have AutoQA source code checked out with write access (ssh:// protocol, requires gitautoqa membership):
git clone ssh://git.fedorahosted.org/git/autoqa.git cd autoqa
Stable release
The following process concerns a stable public release of AutoQA. We use this procedure when we want to officially release a new version of AutoQA for all our users.
Switch Git branch
All the changes must be done in a correct git branch.
- If you want to create a new X.Y.0 major or minor release, create a new release branch:
git checkout -b release-X.Y master
- If you want to create a new revision release X.Y.Z, switch to a corresponding existing release branch:
git checkout release-X.Y
and apply all hotfixes you have prepared.
Update autoqa.spec
and NEWS
Every new release must be mentioned in the rpm spec
file. We also want to provide high-level changes overview in the NEWS
file.
- Edit
autoqa.spec
by incrementing theVersion
and updating the%changelog
- Edit
NEWS
file and add a section for the new release. Document only the most important end-user visible changes. - Locally commit the changes
git commit autoqa.spec NEWS
Tag the release
The last commit (changing the autoqa.spec
file) must be tagged to mark the release.
- Tag the commit:
git tag vX.Y.Z
- Check that the tag was applied to the correct commit by inspecting:
git log --decorate=full
Pull changes back to master
After you tag the release on the release branch, you need to pull the release-related changes (now tagged with vX.Y.Z tag) into the master branch. Merging is a preferred approach, because it ensures the master branch will contain the vX.Y.Z commit. But it is desirable only for a fast-forward merge, otherwise some other changes (we might not want) may be pulled in as well. In that case (e.g. the release branch was used for stabilization and contain several previous commits) we need to use cherry-picking.
- Change to the master branch
git checkout master
- If you created the release branch immediately before tagging a new release, merge the changes using fast-forward approach:
git merge --ff-only release-X.Y
- If you can't use fast-forward merge or it failed, cherry pick the appropriate commit instead:
git cherry-pick vX.Y.Z
Push changes to remote repository
It's time now to push all the changes to the shared remote origin repository.
- Push the release branch changes:
git push --tags origin release-X.Y
- If you modified the master branch (i.e. for major or minor releases), push it too:
git push --tags origin master
Upload tarball
Like many projects, the appropriate method to release a new version is by tarball. Once you have tagged the release, upload a new tarball using the following commands.
- Check-out the correct tag
git checkout vX.Y.Z
- Upload a new release tarball
make upload
Build a source RPM
With the tarball uploaded, it's time to package the new release as an RPM.
- Check-out the correct tag
git checkout vX.Y.Z
- Build a source package
make srpm
Build for applicable releases
With a source RPM created, it's time to build updated packages for any existing stable repositories. This includes Fedora 40, Fedora 39 and, depending on the time of release, potentially Fedora 38. Traditionally, this step would be handled by running the koji build --tag dist-f40-updates path/to/src.rpm
command. However, since
is not yet packaged and available in Fedora repositories, updates are built locally using autoqa
mock
.
- Build packages using mock for Fedora, specify version using
DIST
variable. For possible values forDIST
, consult Packaging:DistTagmake mock DIST=.fc40
- Repeat the build procedure for all desired releases
Create updates
With packages built, it's time to submit them as updates. Traditionally, this step would be handled by using the bodhi update tool. However, since
is not yet packaged and available in official Fedora repositories, a custom package repository is used to deliver updates.
autoqa
- Mirror the autoqa package repository locally
rsync -avz fedorapeople.org:/srv/repos/fedora-qa/autoqa ~/public_html/ ; cd autoqa/
- Add locally built packages to the desired repositories
./move-pkgs.sh path/to/autoqa.git/build/MOCK/*/*.rpm
- Update the yum repo metadata
./update-repos.sh
- Update remote repository with changes
rsync -avz ~/public_html/autoqa fedorapeople.org:/srv/repos/fedora-qa/
- Change permissions on the server so that anyone in gitautoqa FAS group can update the repos
chgrp -R gitautoqa /srv/repos/fedora-qa/autoqa
chmod g+w -R /srv/repos/fedora-qa/autoqa
Cleanup tasks
Purging old release branches
If we are sure we will no longer work on older releases (e.g. before X.Y), we can also delete older release branches. If W < Y, then we can delete release-X.W:
- Make sure there's a tag at the tip of the branch and therefore no work is lost:
git tag --contains origin/release-X.W
This must output some tag (like vX.W.3). Otherwise the branch contains commits which are not part of any tag. - Delete the remote branch:
git push origin :release-X.W
- Prune the local branches (that no longer exist on the remote server):
git remote prune origin
The same goes for deleting older major branches (branches release-Q.Y where Q < X).
Testing release
The following process concerns a testing release of AutoQA. We use this procedure when we want to deploy a testing version of AutoQA onto our staging server for thorough testing.
Build and install RPM
- SSH to the staging server and go to the AutoQA checkout directory (create one if you don't have one).
- Switch to the git branch you want to test, probably master:
git pull; git checkout master
- Build an RPM from current HEAD using the same approach as in #Build for applicable releases, but with appending
DEVEL=1
option:make mock DEVEL=1
- Your user must be in the mock group to be able to run this.
- Install the RPM created in
./build/MOCK/<release>/
.- Since we use
git describe
to generate package versions and sometimes we build and install package from other branches than master, you can actually end up with a package version that is lower than the one currently installed. Instead of usingyum update autoqa-version.rpm
useyum downgrade autoqa-version.rpm
. - Be sure to inspect all
.rpmnew
and.rpmold
files (if they are created, yum will tell you so) and merge the changes.
- Since we use