search

SUSE-Enceladus / public-cloud-info-service

Find IPs of service endpoints, and information about published images.
Apache License 2.0
5 stars 8 forks source link

Enhancement: Utilize bumpcfg for version updates #67

Open jeremy-moffitt opened 3 years ago

jeremy-moffitt commented 3 years ago

For the new version API (see https://github.com/SUSE-Enceladus/public-cloud-info-service/pull/65 ), enable automated version updates using bumpcfg or a similar mechanism.

Acceptance Criteria:

  1. the minor version in the version file is updated automatically as part of the PR merge process
  2. labels or a manual invocation of the bumpversion tool can update major parts of the version number
  3. the automated process can handle the scenario where someone manually updated the version number
rtamalin commented 3 years ago

Just for clarification I was suggesting to use the bumpversion Python package to automate just the management of the version setting in the relevant file in the Python code base.

You can configure this either with a separate bumpversion config file, but you can just as easily put the config settings into the setup.cfg file, e.g. for another project we use the following setup.cfg lines to automate bumping the version in both the setup.py, and a separate VERSION file that the project init.py dynamically loads:

[bumpversion]
current_version = 0.1.8
commit = True
tag = False

[bumpversion:file:setup.py]

[bumpversion:file:testproj/VERSION]

You also need to ensure that bumpversion is included in the requirements used to setup the venv that runs the tooling, which was the requirements-dev.txt file in that project.

With that config you could just run bumpversion at the command line, and it would update the relevant version values to the next revision, e.g. 0.1.9 in the above example, and generate a commit to commit those changes with a commit message along the lines of Bump version: 0.1.8 → 0.1.9.

rtamalin commented 3 years ago

With the above in place the developer workflow could include running bumpversion as part of proposing a change. Or once a number of changes have been merged then a separate bumpversion commit can be generated, proposed, and approved and merged to update the version.

However it should also be possible to implement automation to automatically run bumpversion as a post-merge action, potentially with some guard filters to ignore changes to non-product code, e.g. no automatic version bump for changes to the github config settings, or if the version file was bumped as part of a merge.

And if used in this fashion, you potentially can automate the generation of tags, either using bumpversion's support for tags, or using some additional scripting if that isn't sufficient.