Affects Version/s: None
Fix Version/s: None
Sprint:Platform OS Kanban
QA Risk Assessment:Needs Assessment
Currently, downloading a copy of puppet-runtime is easy if you have the name of its annotated tag - the URLs look like this:
In this case, we can use the version (201803090) to build the URL without issue.
This becomes more difficult when we need an untagged (or unannotated tagged, as shown below) build - in that case, the URL will look like this:
In this case, puppet-agent needs to know both the SHA and the git describe of the runtime revision to construct the URL. Only one of these pieces of information is available in the puppet-runtime component json, which supplies a single git ref. We can't build puppet-agent using a build of puppet-runtime that doesn't have an annotated tag with shipped builds unless we do some manual code editing in the agent's runtime component to specify the URL with both the SHA and the git describe/version.
What to do:
To make this process easier for developers and those without access to Puppet infrastructure, we'd like vanagon to publish the settings yaml (probably the same as/similar to inspect output) alongside the build_metadata.json in the output directory with a name that uses the same version that's used in the directory path – so, something like this:
- With a sha or a tag that someone forgot to annotate: http://builds.puppetlabs.lan/puppet-runtime/de1cb7b08fc22eb416a26a79646f1ffe0fbc3198/artifacts/de1cb7b08fc22eb416a26a79646f1ffe0fbc3198.el-7-x86_64.settings.yaml
- With an annotated tag: http://builds.puppetlabs.lan/puppet-runtime/201804270/artifacts/201804270.el-7-x86_64.settings.yaml
How this could help us:
If these settings yaml files are available in the output directory, our intention is to make additional vanagon changes to use the settings yaml file as the source of settings to inherit when calling inherit_settings in puppet-agent (see
VANAGON-131 for this part). We'll also update the format of the puppet-runtime.json file in puppet-agent along these lines:
Then the puppet-agent build process could proceed like this:
- Use the location and version from the puppet-runtime.json files to construct the correct url to the settings file, whether that's in a local directory or on builds.delivery.
- Build the agent using those settings (instead of requiring a fresh clone of puppet-runtime on each build)
- Also use the location and version information to construct the correct path to the puppet-runtime tarball (whether local or on builds.delivery)
This would let us build and test puppet-agent with puppet-runtime without having to tag, push, and ship the runtime on each new update.