The GitLab CI components now check the atlas-action binary against a checksum that ships with each component release and run the binary of that release, so pinning a component by commit SHA also pins the binary it runs.
From v1.17.9, the GitLab CI components check the atlas-action binary before running it. Each component release includes the SHA-256 checksum of its binary, and the job fails if the downloaded file doesn't match.
The components also run the binary of their own release instead of the latest v1 build, and they no longer download and run a setup script to fetch it. If you pin a component to a commit SHA, the binary it runs is pinned too.
The checksum check is on by default, and existing pipelines need no change.
No Download at Run Time
If atlas is already installed and reports exactly the version set in atlas-version, the components skip the Atlas installer. The arigaio/atlas-action image includes both atlas-action and Atlas, so a job that runs it pinned by digest downloads nothing at run time:
include:- component: $CI_SERVER_FQDN/arigaio/atlas/migrate-lint@<commit-sha>inputs:atlas-version: v1.x.y # the Atlas version installed in the image# ...other inputsatlas-migrate-lint:image:name: arigaio/atlas-action@sha256:<digest>entrypoint: [""]
To find the Atlas version in an image, run:
docker run --rm --entrypoint atlas arigaio/atlas-action:v1.17.9 version