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 release
command (runpip install antsibull
before) to generate CHANGELOG.rst and verify correctness of generated files. - Commit changes to
changelog.yaml
andgalaxy.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-only
git 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-release
has 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.gz
file 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 Version
and upload your release*.tar.gz
, e.g.openstack-cloud-1.5.0.tar.gz
. Push collection tarballs to theopenstack.cloud
namespace requires membership inopenstack
namespace on Ansible Galaxy. - Instead of using Ansible Galaxy web interface, you could also upload your release from cli. For example:
whereansible-galaxy collection publish --token $API_GALAXY_TOKEN -v /path/to/openstack-cloud-1.5.0.tar.gz
$API_GALAXY_TOKEN
is 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-openstack
wheresshnaidm
has to be replaced with your username. cd ansible-collections-openstack
and go to branchrawhide
withfedpkg switch-branch rawhide
.- Download new collection sources from Ansible Galaxy using
wget https://galaxy.ansible.com/download/openstack-cloud-<version_tag>.tar.gz
where<version_tag>
is a your new version, e.g.1.10.0
. Or runspectool -g *.spec
after having changed the*.spec
file in the next step. - Bump version in
*.spec
file 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
*.spec
file 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
rawhide
withfedpkg 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.