We recently released v3 of julia-actions/setup-julia, which is a GitHub Action that installs Julia for use in your GitHub Actions CI jobs. I want to talk a bit about the tags on that repo. This discussion only affects the latest tag and tags of the form vX.Y (e.g. v2.7). If you don’t use those tags, you can skip the rest of this post.
Changes
In the past (for setup-julia v1 and v2), we maintained a tag called latest, which pointed to the absolute latest version of setup-julia. Going forward, for setup-julia v3 and later, we will no longer update the latest tag. So you should stop using the latest tag going forward.
In the past (for setup-julia v1 and v2), we would maintain tags of the form vX.Y (e.g. v2.7). Going forward, for setup-julia v3 and later, we will not be creating tags of the form vX.Y. So you should stop using the vX.Y tags going forward.
Recommendation
We recommend that most people pin setup-julia to the full-length commit hash, for example:
- uses: julia-actions/setup-julia@f6f565d9f7cf12f53dc8045742460d6260ad3b39 # v3.0.1
And then use Dependabot (or a similar tool, such as Renovate) to keep those commit hashes up-to-date.
But if you don’t want to use a full-length commit hash, you can instead use the v3 convenience tag, for example:
- uses: julia-actions/setup-julia@v3
I currently use:
strategy:
fail-fast: false
matrix:
version:
- '1.11'
- '1.12'
os:
- ubuntu-latest
- windows-latest
arch:
- x64
steps:
- uses: actions/checkout@v6
- uses: julia-actions/setup-julia@v2
with:
version: ${{ matrix.version }}
arch: ${{ matrix.arch }}
Would I have to change that?
You can use that same approach. Although you should upgrade from setup-julia@v2 to setup-julia@v3.
Also, for most use cases, you can get rid of arch entirely - remove it from your matrix, and remove it when calling setup-julia. When you omit arch, setup-julia will automatically choose the architecture of the runner that you’re running on, which is the right behavior for most use cases.
So, your code example would become:
strategy:
fail-fast: false
matrix:
version:
- '1.11'
- '1.12'
os:
- ubuntu-latest
- windows-latest
steps:
- uses: actions/checkout@v6
- uses: julia-actions/setup-julia@v3
with:
version: ${{ matrix.version }}
Where would one find evidence (or even an assertion) that, say,
julia-actions/setup-julia@f6f565d9f7cf12f53dc8045742460d6260ad3b39
has passed some sort of security review?
It is just the commit which v3 and v3.0.1 (at the time of writing) is pointing to, see julia-actions/setup-julia/tags. The reason for using an explicit commit is that tags are mutable so e.g. v3.0.1 doesn’t necessarily point to the same commit the next time you run the action. In fact, that is how the v3 tag is maintained, it is deleted and recreated whenever there is a new release in the v.3.x.y release series so that it always points to the latest one.
Yeah, to be clear, there is no assertion/evidence of a security review as there is no formal “security review” at all. That isn’t something most open source projects have the resources to provide. (Code reviewers of course review PRs for correctness including security, but there is no separate security review step). The hash just makes it so at least you can figure out what code you are running at all, and so that it can’t change “behind your back”. So if malicious code does get pushed to the action (e.g. by a maintainer’s github account being compromised), (1) you don’t run it by default, instead you need to update the hash which takes time, and (2) you can check what version of the code you are running so you know if you are vulnerable and what to remediate.
Oh come on, yet another Dependabot chore. Just let me use @latest and forget about it.