Make Actions/Reusable Workflow Calls Use Relative Refs

[CodeGat]

Background

Currently, our actions and reusable workflows are in the ORG/REPO/.../REUSABLE@vX format, in which we update the vX for each major version.

This has it's own loopholes, though - if a minor/patch version (from an Entrypoint Workflow POV) actually changes functionality in an intra-workflow/intra-action way that is not compatible, there will be issues.

Implementation Details

For Actions

For actions that are housed in build-cd, we should do the following instead:

- uses: actions/checkout@v5
  with:
    repository: access-nri/build-cd
    ref: ${{ github.workflow_sha }}

- uses: ./.github/actions/ACTION
  # ...

For Workflows

For workflows that are housed in build-cd, we should do the following instead:

uses: ./.github.workflows/WORKFLOW
# ...

Thanks @atteggiani for helping me out coming to this (far better) solution!

[CodeGat]

Note that there might be issues with this. github.workflow_sha is from the caller repositories perspective, and we can't get the ref of the callee unless it was an input:

uses: workflow.yml@v1.2.3
with:
  workflow_ref: v1.2.3

[CodeGat]

Some other solutions...

• Specifically for actions: Still use relative refs, but when checking out the repository with the action, make ref: populated in a central, workflow-level env.INFRA_REF: v1.2.3 - at least there is less places to update the value. This doesn't fix workflows, though. For example:

env:
  INFRA_REF: v9
jobs:
  a:
    steps:
      - uses: actions/checkout@v4
        with:
          repository: org/my-infra-repo
          ref: ${{ env.INFRA_REF }}
      - uses: ./.github/actions/action

• Create a workflow that updates refs for intra-workflow refs as part of an infrastructure repository PR, so it's at least not a manual process...

on:
  issue_comment:
jobs:
  update-refs:
    if: startsWith(github.event.comment.body, '!update-ref')
    steps:
      # Logic that parses a !update-ref v1.2.3 command, then...
      - run: sed -E -i 's|(uses: access-nri/build-cd/.+)@v.+|\1@v${{ step.setup.outputs.version }}|g' .github/workflows/*
      # commit to the PR, etc...

Whaddaya reckon @atteggiani ?? Option 2 sounds alright...I could add it to ACCESS-NRI/actions for us...

[atteggiani]

Thanks @CodeGat for listing and documenting possible options!

I think your Option 2 is the most feasible so far, even though it would still need to be triggered manually (by commenting in the PR). Also, depending on the infrastructure, it might have different workflows/actions versions that it needs to modify, so a similar sed command would be needed for all the cases.

I think the appropriate solution might depend on how "new releases" of the infrastructure are taking place.
Does a new infrastrucure version get released anytime a PR gets merged? Do releases happen "manually" by pushing a version tag when "it feels like it's the right time to release a new version"? What's the current criteria for new releases in the build-ci infrastructure?

In the case of ACCESS-NRI/documentation-infra, I was thinking it might make sense to manually trigger new version releases by running a workflow that internally pushes the new release tag.
The workflow could also automatically update the workflows/actions versions in the internal files to match the version that is being released.

This "release workflow" for infrastructure repos would probably need to be tailored and specific to each infra repo, but I would need more information on all the "release requirements" to be 100% sure things cannot be generalised with proper inputs into a reusable workflow. At the end of the day I guess the overall steps that need to happen for a new infrastructure release are very similar across different infra repos.

What do you think about the "new infrastructure version release workflow" idea?