Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Use a tag in
create-job-server-pr.yml
`just update-interactive-templates` in job-server currently requires a repository tag to be specified. So what was happening prior to this commit: 1. `just update-interactive-templates` in the job-server repository, runs with the variable `GITHUB_SHA` passed to it. 1. `update-interactive-templates` uses this value when updating the requirements. The `GITHUB_SHA` is a commit hash and does not correspond to a tag, `update-interactive-templates` then rewrites the requirements file to point to a URL of the format: `https://github.com/opensafely-core/interactive-templates/archive/refs/tags/<commit_hash>.zip' 1. The requirements are rebuilt with `pip-tools`. This fails as the updated URL for `interactive-templates` does not exist. We're looking for a literal tag that *is* a commit hash, and our actual tags are release versions specified as `v2024.…` Perhaps the intent here was originally to match a commit SHA to a tag? And we could change `update-interactive-templates` to find the tag for a given commit. But, by sticking with a tag — how `update-interactive-templates` works — instead of using a commit SHA, we also solve the following issue when running this workflow via `workflow_dispatch`. Let's say: 1. We made a new release with a specific version. 2. The release fails due to some error in the workflow. 3. We fix up the workflow and merge that fix. 4. We then try and re-release the version, but if `update-interactive-templates` is looking for a commit SHA to match to a tag, that commit SHA when the workflow dispatch runs won't match the release tag, so will still fail. Instead, let's simplify things: in all cases that this workflow is run, we pick the most recent tag, and if there's any change to the requirements file, then create the PR in job-server.
- Loading branch information