Maintainers
For each OpenHPC release, a set of components are identified for build within our distributed OBS infrastructure. In general, a GitHub issue tracker should be created for each component and associated with the appropriate milestone version.
Prior to committing changes to the underlying .spec file for a given component, the package needs to be registered with the associated project in our OBS instance. Once this step is completed by an OBS administrator, the obs_ready label will be added to the issue tracker. At this point, you are free to begin submitting PR updates against the latest factory branch in git. When changes land on the current version branch, a webhook will automatically trigger builds in OBS for the relevant component.
Note that until the first commit occurs for a package to be updated, the corresponding package in OBS remains in a lock state as highlighted in the web UI screenshot below. It will also include a special marker file (_obs_config_ready_for_build) which will be removed automatically on first commit.
When committing changes to update the component version, add/remove patches, update build config, etc, please include the relevant GitHuB issue tracker at the end of the commit log. In this cmake example, we wanted to bump the version to v3.13.4 as stipulated in #894 and the relevant commit log was:
dev-tools/cmake: update to v3.13.4 (#894)
Recall that a git commit hook is posted on the wiki which you can use locally to highlight the component being changed.
After landing changes, you should double check in OBS that the correct source tarball version has been pulled into OBS. Once happy with the build (checking no failures on desired OS/architecture combinations), you can add the built label to the relevant issue tracker. An example OBS screenshot from this cmake example post-commit shows the correct tarball version and all builds complete is shown below.
