obs-service-replace_using_package_version

An OBS service to replace a regex with some package version available in the build time environment or repositories.

This service makes sense mostly in buildtime mode.

Development

This is a python project that makes use of setuptools and virtual environment.

To set the development environment consider the following commands:

# Get into the repository folder
$ cd obs-service-replace_using_package_version

# Initiate the python3 virtualenv
$ poetry shell

# Install the project and dependencies into the virtual env
$ poetry install

# Run tests and code style checks
$ tox

Find poetry installation guide here if the host distro does not provide poetry.

Cutting a new release

This python project makes use of the bumpversion utility. It is configured via the .bumpversion.cfg file.

The utility commits the version change in the required files and creates a new tag in the local git repository.

For instance a new patch version is created as:

$ bumpversion patch
$ git push origin master
$ git push origin <new_version_tag>

This replace_using_package_version utility is packaged and maintained in the Open Build Service inside the project Virtualization:containers. The package in OBS is configured to manually pull the latest tag from this repository. Updating the OBS package to the latest release is done as follows:

# Checkout the package locally
$ osc co Virtualization:containers obs-service-replace_using_package_version

# Change into the working copy
$ cd Virtualization:containers/obs-service-replace_using_package_version

# Run the SCM service manually, it udpates the source to the latest version
$ osc service mr

# Commit the changes
# note that some metadata files are generated but not comitted
$ osc commit -m "Updating source generated by the SCM service"

Usage

Consider a _service file that includes the following:

<service name="replace_using_package_version" mode="buildtime">
  <param name="file">mariadb-setup.sh</param>
  <param name="regex">%%TAG%%</param>
  <param name="package">mariadb</param>
  <param name="parse-version">minor</param>
</service>

The service in this case would look for the mariadb package in the build environment, get its version, and try to replace any occurrence of %%TAG%% in the mariadb-setup.sh file with the mariadb package version.

In case the mariadb rpm package is not found within the build environment it will also try to fecth the version from a mariadb.obsinfo file if any. The service fails if no version can be determined.

*.obsinfo files are metadata files produced by the obs_scm service, which is essentially used to retrieve sources from source repositories. This can be useful for some corner cases in which the required package version is not part of the build dependencies (this is likely to happen for helm chart builds).

The file parameter is optional and when omitted it will default to the package's build recipe file, e.g. Dockerfile or mariadb-image.kiwi.

The parse-version could be skipped or if parameter's regular expression doesn't match then full package version is returned.

Possible parse-version values and it returned value in X.Y.Z.N version:

• major: ^(\d+), returns X
• minor: ^(\d+(\.\d+){0,1}), returns X.Y
• patch: ^(\d+(\.\d+){0,2}), returns X.Y.Z
• patch_update: ^(\d+(\.\d+){0,3}), returns X.Y.Z.N
• offset: ^(?:\d+(?:\.\d+){0,3})[+-.~](?:git|svn|cvs)(\d+)
  • returns X.Y.Z.N as it doesn't match
  • but if you have offset in your version X.Y.Z+git5 it returns 5
• parse-version is absent or parameter doesn't match, returns X.Y.Z.N

For instance, in this specific case, the service will apply the ^(\d+(\.\d+){0,1}) regular expression and use only the first match. In case mariadb version was 10.3.4~git_r154 only the 10.3 part would be used as the replacement string.

You could use this service multiple times in your _service file so offset parameter could be used in case you need more unique identification. For example %%TAG%%.%%OFFSET%% if you add another service with regex "%%OFFSET%%" and parse-version "offset".

This service is mainly designed to work in buildtime mode, so it is applied inside the build environment just before the start of the build.