Build and Release - Enstore-org/enstore GitHub Wiki
Overview
Enstore currently has an automated build and release process for its development branch only. This is achieved through Github actions. Build attempts can be seen in the actions pane here, and successful releases can be found in the releases pane here.
See also: A slightly newer bit of documentation is here.
Workflow Details
Enstore is built by a github workflow when a change to the rpm_version file (or when the workflow is triggered manually, but this can lead to tag collisions).
The intended developer workflow is for developers to:
- Make changes to code, and push to develop branch
- Changes to src/ or modules/ directory result in an automatic run of the unit test workflow
- Bump version number, push to develop branch with a quick description of the version change
- This results in an automatic run of the build and release workflow
The workflow itself:
- Creates an RPM spec file with the new rpm version via a short script, including a suffix if the rpm is
nonprod
- Generates patchnotes from Git commits to src/ and modules/ directories, compiles them and commits them to the release-notes dir
- Builds the RPM according to the generated spec file
- Creates a tag in Github with the generated release name as the tag name
- Uploads the new RPM as an release artifact of the tag
Deployment and Promotion
There is currently no standard process for deploying rpms from Github to target instances, or for promoting rpms from nonprod to production. At FNAL, we plan to implement automation to pull new release versions to a local yum repository for staging and evaluation, and then submit qualified code to the production branch for the creation of a prod rpm, but these plans are still in consideration.
Known Issues
- Because of templating in the spec file used for this process, the manual RPM build process is now complicated by the need to run the build_versioned_spec script
- This process is not yet implemented for the production branch