This package offers tools to release (tag) packages that follow Bob’s
development guidelines. It automatically updates the
README.rst file of
the package to setup the correct pointers for the release build and
documentation badges. The tools are setup to ensure a changelog is provided
with each release. The changelog can be autogenerated from merge-requests or
commits in the target package.
Using these scripts is a 2-step process:
Generate a changelog using
bdt gitlab changelog
Tag a release using
bdt gitlab release
--help flag in each command to learn more about each command.
While beta builds of packages will use the beta version of this package, stable will look for the latest stable version of this package for their build configuration.
To correctly produce a release, ensure a STABLE version of bob.devtools is properly released before you start tagging packages. The builds will then use such version of this package to enforce the correct build environment during the packaging.
If you forget to properly tag this package before doing so you risk building against the wrong set of dependencies.
Manually update changelog¶
These instructions may be outdated!!
The changelog since the last release can be found in the file
bob/devtools/data/changelog_since_last_release.md. The structure is
documented as part of the help message of
bdt gitlab release. Read it.
To manually update the changelog, follow these guidelines:
For each tag, summarize the commits into several descriptive lines. These summaries become tag descriptions and they should extend/update the existing tag description. Therefore, each line of the summary should also start with
*character like the tag descriptions.
The last tag name is called
patch. This indicates that a patch version of this package will be automatically updated during the next tag/release. You can change
major, and the package will be then tagged/released with either minor or major version bump. You may also set an explicit tag to the package (e.g.
v1.0.0), which may be required if no tags are available yet on gitlab.
Once all commits were changed to corresponding tag descriptions (no more lines start with
-characters), this package is ready for release and you can continue to another package in the changelog.
Releasing the Bob meta package¶
Here are the instructions to release Bob meta package:
$ cd bob $ bdt gitlab update-bob -vvv --stable
The script above cannot identify linux only packages. After running the script, you need to manually tag linux only packages in both
requirements.txt. For example, in
- bob.ip.binseg ==1.1.0 # [linux]
bob.ip.binseg ==1.1.0 ; sys_platform == 'linux'
Test the conda recipe of bob. You may want to cancel the command below once it reaches the nosetests.:
$ bdt build -vv --stable
Commit the changes and push:
$ git commit -m "Pinning packages for the next release. [skip ci]" conda/meta.yaml requirements.txt $ git push
Tag the package using the same changelog mechanism that you used to tag other packages. Assuming the changelog has a
$ bdt gitlab release -vvv CHANGELOG --package bob/bob
When the script says
Waiting for the pipeline *** of "bob/bob" to finish, you may cancel it and check the progress online.
To revert the pins while in beta run:
$ git pull --rebase $ bdt gitlab update-bob -vvv --beta
Like before, tag the linux only packages manually.
Commit and push the changes:
$ git commit -m "Remove package pins while in beta. [skip ci]" conda/meta.yaml requirements.txt $ git push
You can see that if we could identify linux only packages automatically, the whole
release process would have been only to run
bdt gitlab release -vvv CHANGELOG --package bob/bob.
Do you want to help fix that?