You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: action.yml
+44-16Lines changed: 44 additions & 16 deletions
Original file line number
Diff line number
Diff line change
@@ -232,6 +232,10 @@ inputs:
232
232
description: "(orchestrator only) the spec to pass onto digger cli"
233
233
required: false
234
234
default: ""
235
+
digger-version:
236
+
description: "Pre-compiled version of digger CLI to install. Must correspond to a valid release tag (vX.Y.Z). This value overrides the version derived from the github.action_ref."
237
+
required: false
238
+
default: ""
235
239
236
240
outputs:
237
241
output:
@@ -245,6 +249,30 @@ runs:
245
249
run: echo digger run ${{ inputs.id }}
246
250
shell: bash
247
251
252
+
- name: Determine binary mode (local, build, or pre-built)
description: "For serious usecases always use a pinned version which is of the form @vX.Y.Z since this will download a compiled binary. In addition to being faster to run, it is also more secure than using a commit from a branch"
2
+
title: "Specifying Version"
4
3
---
5
4
6
5
<Warning>
7
-
For serious usecases always use a pinned version which is of the form @vX.Y.Z
8
-
since this will download a compiled binary. In addition to being faster to run, it
9
-
is also more secure than using a commit from a branch
6
+
For production use cases it is best to pin the version of the action with the commit hash (e.g. `-uses: diggerhq/digger@<COMMIT_HASH>`) of the desired release
7
+
AND specify the `digger-version` input to be a tagged release (`vX.Y.Z`).
8
+
9
+
This provides the security of ensuring the same action code is executed each time with the performance of using a pre-compiled Digger binary.
For production usage, we recommend pinning the action to the commit hash of a released version AND specifying a Digger CLI version via the `digger-version` input.
13
15
14
-
The default and recommended way of versioning Digger is to use the vLatest tag, which always points to the latest release. The difference compared to just specifying "latest" is that it is a release with pre-built binaries, so it is faster than building from a branch, which using "latest" effectively does.
16
+
Specifying the action commit hash is the only way to ensure the same version of a GitHub Action is executed each time and helps protect against supply chain attacks such as [CVE-2025-30066](https://www.wiz.io/blog/github-action-tj-actions-changed-files-supply-chain-attack-cve-2025-30066).
17
+
18
+
The `digger-version` input enables pinning to the hash while ALSO using a pre-built Digger cli binary.
To pin a specific release of Digger, you can use `@vX.Y.Z` tag in your workflow file:
29
+
For non-production use cases, you can specify the `vLatest` tag to use the latest tagged release for the digger action and the Digger CLI.
30
+
31
+
The difference compared to just specifying "latest" is that it is a release with pre-built binaries, so it is faster than building from a branch, which using "latest" effectively does.
If you aren't worried about supply chain attacks but want stability of using a specific release, you can pin the action to a specific release of Digger.
41
+
42
+
This will infer the Digger cli version to use based on the version of the action using `github.action_ref` and install the corresponding pre-built binary.
0 commit comments