Skip to content

Build Process

Jump to bottom
renbauer-fnal edited this page Dec 7, 2023 · 6 revisions

Components:

  1. Docker Image
  2. Build / (Sign) / Release Workflow
  3. Pull to Enstore repo
  4. Install on Enstore Machines
  5. Run Test Infrastructure

Detailed Steps

Docker Image

Docker file for the image is in this repo here.

This file basically just builds an SL7 image with the dependencies necessary to build Enstore, and some scripts to allow RPM signing during the build process.

This is typically built on a test Enstore machine when changes need to be made, and is uploaded to dockerhub here.

Build / (Sign) / Release Workflow

Enstore is built, signed, and released in the 'Build RPM and Release' workflow which is defined in this repo here.

This workflow runs automatically when the rpm_version file is updated on the production or develop branch. It can also be run manually on other branches, but if the rpm_version file has not been updated in that branch it will result in a naming collision with the release that has already been created from the develop branch.

All releases generated by this workflow will have nonprod in their name UNLESS it is run on the production branch specifically. These runs are generally triggered automatically by a merge from the develop branch to the production branch which includes a change to the rpm_version file.

This workflow does many things, so we will explain each step -

  1. Prepare Build Files: Moves some files around to prepare for build.
  2. Apply RPM Version: Invokes the build_versioned_rpm script, which updates the RPM spec file (which is symlinked to by this file) to replace some macros with values from the rpm_version file. Also, determines the RPM version and saves this value in output variables for use in future steps.
  3. Work Around Dubious Ownership Permissions Issue: This is a fix from a github bug to prevent file permission issues.
  4. Generate Release Notes: Runs git log to generate commit notes since the last release, and write them to a file under release_notes.
  5. stefanzweifel/git-auto-commit-action@v4: This just pushes those release notes to the branch this workflow is running against, resulting in commits like this.
  6. Build Enstore RPM: Runs the actual RPM build.
  7. Sign Enstore RPM: Signs the RPM using the scripts included in the docker image. Keys are stored as Github secrets, so they are not exposed to anyone who downloads the docker image.
  8. Create Release: Creates the release in Github, which look like this.
  9. Upload Enstore RPM as Release Asset: Uploads the Enstore RPM so it can be downloaded from the release - see the Assets section of the release linked above.
  10. Wait to Retry RPM Upload: Sometimes the asset upload can fail, so if that happens this sleeps for 5 seconds to wait a bit before trying again.
  11. Upload Enstore RPM as Release Asset (Retry): Retry uploading the release asset in case there was a failure. Unfortunately there is no way to retry automatically, so in very rare cases these can both fail and the whole build will have to be re-run.

Pull to Enstore repo

Because our repo is firewalled and can only be accessed from the VPN, it is not possible for Github to push the Enstore rpms directly to our repo. So, we have a script to pull the rpm to our repo on the repo machine. This script is not on Github as we don't want the details of how it scrapes and downloads data to the repo to be public, but it can be found in the root directory of our repo machine. In order to invoke the script, run:

./download_enstore_releases.sh -d <nonprod_repodir> for nonprod, or ./download_enstore_releases.sh -p -d <repodir> for prod.

In short, this will download the rpms from any releases live on Github which have the correct name and are not currently in the repo, verify their signatures, and update the repos so they are exposed.

Install on Enstore Machines

This can be done through rgang or on each machine. Remember the Enstore rpms are disabled by default, so they must be enabled in yum in order to install the repos.

Note nonprod and prod Enstore rpms have the same name, so the one you get will depend on which repo you have enabled.

Run Test Infrastructure

Qualification testing for Enstore ships along with the rpm under the tools directory. For more details on how to run qualification, see the enstore-test-files repo.

Clone this wiki locally