...

Status
colour Red title TODO

releng-misc Bolt project

releng::download_assets_from_puppetfile

Status
colour Red title TODO

Lifecycles

...

Status
colour Red title TODO

Building and Signing RPMs

Updating the Download Server Repositories

Updating experimental repositories with a SIMP release’s GitHub RPMs

Running the following Bolt plan (from releng-misc) will download RPMs from GitHub releases and stage them local yum repositories:

bolt plan run releng::createrepos_from_puppetfile_assets \
  --inventory inventory--github-only.yaml

The plan:

1. Determines what to download by referencing Puppetfile.pinned in simp-core’s master branch:

   • A :tag 's corresponding GitHub release

   • The HEAD-most tagged GitHub release along a repo’s tracking :branch

     • NOTE: The plan looks a maximum of 30 commits back to find the HEAD-most release

2. Downloads all assets from each repo’s GitHub release into a _release_assets/ directory

3. Creates four subdirectories containing yum repositories and hard-linked RPMs

...

...

1. :

   • _release_assets/el8/

   • _release_assets/el7/

   • _release_assets/el8.src/

   • _release_assets/el7.src/

These directories can be transferred to the SIMP download server and used during development.

Uploading SIMP RPMs to the download server

Publishing to the download server is currently manual process.

Use rsync -n to check what will change before uploading RPMs:

rsync -avzn --delete _release_assets/el8/ \
  enterprise-download.simp-project.com:/data/community-download/simp/yum/experimenta
l/6/el/8Server/x86_64/simp/

After confirming the changes, run the command again without the -n

Updating a super-release’s dep repositories with bolt-pulp3

Currently only the repo_packages.yaml file for EL8 is maintained. It has recently been moved to simp-core. Read the project’s README and`bolt plan show` for instructions.

Manually triggering GHA RPM builds

In situations where GHA should

The release_rpms.yml workflow will release/build/sign/attach RPMs fora component’s GitHub release. It is automatically triggered by its repo's tag_deploy*.yml workflow, following its GitHub release. The workflow file is a standardized asset, and is present in every SIMP component repo that builds its own RPMs.

RPMs . It is automatically triggered as part of a repo’s tag_deploy*.yml workflow, but it can also be manual triggered manually to release/build/sign/attach RPMs forare built by running the rake task pkg:single inside the SIMP build container

• This is done to ensure that RPMs are built using the overrides in simp-core’s build/rpm/dependencies.yaml file.

RPMs are signed within a centos8 SIMP build container, using a GPG key that is only available to workflows running under the simp/ GitHub org.

Manually triggering GHA RPM builds

The release_rpms.yml workflow can be triggered manually from the GitHub web interface and API. This can be necessary when the target is a forked repo mirror without its own tag_deploy_*.yml workflows, or an error prevented GHA from building RPMs during a component’s tagged release.

The workflow has many configurable options when triggered manually. Notably, it can be configured to release, build, and attach signed RPMs to tagged commites in any other repository under the simp/ org. This requires a

The manual trigger has the following requirements:

• A GitHub token with sufficient scope

...

• A target GitHub release, or at the very least, a tag commit (the workflow can optionally create a release from a pre-existing taga)

• The repo must be able to build RPMs from simp-core, using rake pkg:single

To manually trigger an RPM build:

1. From a SIMP component repo’s GitHub actions UI, select the RELENG: Build + attach RPMs to GitHub Release action

2. Click the “Run workflow” drop-down in the upper right

3. Fill out the relevant inputs, including an API token (and optionally, a different target repo)

4. Click “Run workflow”

...

Status
colour Red title TODO

Notable exceptions