Co-Authored-By: Sagi Shnaidman <sshnaidm@redhat.com> Change-Id: Ib94adb1c6d6237800db13b3cc243e0897aa6a49f
7.9 KiB
Release process for Ansible OpenStack collection
Publishing to Ansible Galaxy
- Create entry in changelog.yaml with commits since last release.
- Modules should be in a separate section
modules - Bugfixes and minor changes in their sections
- Modules should be in a separate section
- Change version in galaxy.yml. Apply Semantic Versioning:
- Increase major version for breaking changes or modules were removed
- Increase minor version when modules were added
- Increase patch version for bugfixes
- Run
antsibull-changelog releasecommand (runpip install antsibullbefore) to generate CHANGELOG.rst and verify correctness of generated files. - Commit changes to
changelog.yamlandgalaxy.yml, submit patch and wait until it has been merged - Tag the release with version as it's described in OpenStack docs:
- Make sure you have a valid GnuPG key pair
git checkout <your_branch>git pull --ff-onlygit tag -s <version number>where<version number>is your taggit push gerrit <version number>
- When your tag has been pushed in the previous step, our release job
ansible-collections-openstack-release, defined in galaxy.yml, will run automatically and publish a new release with your tag to Ansible Galaxy. When it has finished, its status and logs can be accessed on Zuul CI's builds page. - When release job
ansible-collections-openstack-releasehas failed, you can manually build the collection locally and publish your release to Ansible Galaxy:git checkout <version number>where<version number>is your tag- Delete untracked files and directories with
git clean -n; git clean -fd - Build collection with
ansible-galaxy, for example:
ansible-galaxy collection build --force --output-path /path/to/collection/dir- On success you will find a
*.tar.gzfile in/path/to/collection/dir, e.g.openstack-cloud-1.5.0.tar.gz - Go to your content page on Ansible Galaxy, open namespace
openstack, click onUpload New Versionand upload your release*.tar.gz, e.g.openstack-cloud-1.5.0.tar.gz. Push collection tarballs to theopenstack.cloudnamespace requires membership inopenstacknamespace on Ansible Galaxy. - Instead of using Ansible Galaxy web interface, you could also upload your release from cli. For example:
where
ansible-galaxy collection publish --token $API_GALAXY_TOKEN -v /path/to/openstack-cloud-1.5.0.tar.gz$API_GALAXY_TOKENis your API key from Ansible Galaxy. - Monitor import progress on Ansible Galaxy and act accordingly to issues.
- Announce new release to The Bullhorn: Join Ansible Social room on Matrix and mention newsbot to have your news item tagged for review for the next issue!
Publishing to Fedora
NOTE: Before publishing an updated RPM for Fedora or RDO, contact Alfredo Moralejo Alonso amoralej@redhat.com
(amoralej) or Joel Capitao jcapitao@redhat.com (jcapitao[m]) in #rdo on OFTC IRC about the
latest release process.
NOTE: If your username is in Fedora's admins group, you can push your commit directly to Fedora's repository for
Ansible OpenStack collection. Otherwise you will have to open pull requests to sent changes.
- Get familiar with packaging for Fedora. Useful resources are:
- Install all necessary packaging tools, mainly
fedpkg. - Create a scratch space with
mkdir fedora-scm. - Fork Fedora repository rpms/ansible-collections-openstack.
- Clone rpms/ansible-collections-openstack with
fedpkg clone rpms/ansible-collections-openstack. Or clone your forked repository (something likehttps://src.fedoraproject.org/fork/sshnaidm/rpms/ansible-collections-openstack) withfedpkg clone forks/sshnaidm/rpms/ansible-collections-openstackwheresshnaidmhas to be replaced with your username. cd ansible-collections-openstackand go to branchrawhidewithfedpkg switch-branch rawhide.- Download new collection sources from Ansible Galaxy using
wget https://galaxy.ansible.com/download/openstack-cloud-<version_tag>.tar.gzwhere<version_tag>is a your new version, e.g.1.10.0. Or runspectool -g *.specafter having changed the*.specfile in the next step. - Bump version in
*.specfile as in this example for1.9.4:+Version: <version-tag> +Release: 1%{?dist}
and add changelog, sort of:
+* Tue Jun 08 2021 Sagi Shnaidman <sshnaidm@redhat.com> - <version-tag>-1
+- Bump to <version-tag>-1
- Upload sources you downloaded before with
fedpkg new-sources <version-tag>.tar.gz. - Optionally check build with
fedpkg mockbuild. - Verify and commit updated
*.specfile with:fedpkg diff fedpkg lint # run linters against your changes fedpkg commit # with message such as 'Bumped Ansible OpenStack collection to <version-tag>' - Push changes for
rawhidewithfedpkg push. - Ask Koji to build your package with
fedpkg build. - Optionally check Koji's page for
ansible-collections-openstack. - Repeat release process for older Fedora branches such as Fedora 36 aka
f36:fedpkg switch-branch f36 git merge rawhide fedpkg push fedpkg build fedpkg update # or use Bodhi's page "Create New Update" at https://bodhi.fedoraproject.org/updates/new
Publishing to RDO
NOTE: Before publishing an updated RPM for Fedora or RDO, contact Alfredo Moralejo Alonso amoralej@redhat.com
(amoralej) or Joel Capitao jcapitao@redhat.com (jcapitao[m]) in #rdo on OFTC IRC about the
latest release process.
All master branches on RDO trunk consume code from the master branch of the Ansible
OpenStack collection. Its RPM is (re)build whenever a new patch has been merged to the collection repository. Afterwards
it is promoted as any other TripleO components in client component CI.
To update stable RDO branches such as CentOS 9 Zed, patches have to be
submitted to CentOS Cloud SIG repositories. In this case, create a patch for stable branches such as wallaby-rdo, and
ussuri-rdo at ansible-collections-openstack-distgit. Example.