VirtusLab
GitHub Action release not found
https://github.com/enola-dev/enola/actions/runs/13642412830/job/38134933735
Run VirtusLab/bazel-steward@da4afb73b57160cb1e9663d4b89bae0ec75a7a71
Warning: Unexpected input(s) 'distribution', valid inputs are ['java-version', 'java-package', 'architecture', 'jdkFile', 'server-id', 'server-username', 'server-password', 'settings-path', 'gpg-private-key', 'gpg-passphrase']
Run actions/setup-java@v1
/usr/bin/tar --version
tar (GNU tar) 1.35
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by John Gilmore and Jay Fenlason.
/usr/bin/tar xz --warning=no-unknown-keyword -C /home/runner/work/_temp/temp_30370[8](https://github.com/enola-dev/enola/actions/runs/13642412830/job/38134933735#step:3:9)515 -f /home/runner/work/_temp/ef33049b-c0cf-44d6-987b-a19b29e1b852
creating settings.xml with server-id: github; environment variables: username=$GITHUB_ACTOR, *** and gpg-passphrase=null
writing /home/runner/.m2/settings.xml
Run TAG_PATTERN=$(echo "/home/runner/work/_actions/VirtusLab/bazel-steward/da4afb73b57160cb1e[9](https://github.com/enola-dev/enola/actions/runs/13642412830/job/38134933735#step:3:10)663d4b89bae0ec75a7a71" | grep -Po "(?<=\/)[^\/]*$")
TAG_PATTERN=$(echo "/home/runner/work/_actions/VirtusLab/bazel-steward/da4afb73b57160cb1e9663d4b89bae0ec75a7a71" | grep -Po "(?<=\/)[^\/]*$")
if [[ $TAG_PATTERN == v* ]] ;
then
TAG_NAME=$(gh release list -L 100 --repo $REPOSITORY | grep -Eo '^'"$TAG_PATTERN"'[\.0-9]*' | sort -Vr | head -n 1)
else
TAG_NAME=$TAG_PATTERN
fi
gh release download $TAG_NAME --pattern bazel-steward.jar --repo $REPOSITORY
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
env:
JAVA_HOME_11.0.[26](https://github.com/enola-dev/enola/actions/runs/13642412830/job/38134933735#step:3:28)_x64: /opt/hostedtoolcache/jdk/11.0.26/x64
JAVA_HOME: /opt/hostedtoolcache/jdk/11.0.26/x64
JAVA_HOME_11_0_26_X64: /opt/hostedtoolcache/jdk/11.0.26/x64
GH_TOKEN: ***
REPOSITORY: VirtusLab/bazel-steward
release not found
Error: Process completed with exit code 1.
Huh, both https://cli.github.com/manual/gh_release_list and https://cli.github.com/manual/gh_release_download seem to exist?!
I cannot immediately spot what the problem here is.
But staring at this: https://github.com/VirtusLab/bazel-steward/blob/dc5fe31e5accbbdab75b10ac4df6826fda31c780/action.yaml#L35
I suspect that this is because I have uses: VirtusLab/bazel-steward@da4afb73b57160cb1e9663d4b89bae0ec75a7a71 # v1.6.0 here.
IMHO Bazel Steward should still work with that and not have "magic version picking" that prevents one from using this; perhaps that could be fixed or improved in this issue.
In the meantime, I suspect that I can work around it by using a version tag instead of a revision. Except that I don't like doing that very much.
Except that I don't like doing that very much.
Background:
- https://openssf.org/
- https://www.bestpractices.dev/en/projects/7865
- https://securityscorecards.dev/viewer/?uri=github.com/MariaDB4j/MariaDB4j
- https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies
FYI https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#security
Hmm, do you have an idea how to set it up in a secure way? It would need to be built from sources on each run I guess if we want to point to a commit. I see that setup-node just commits the dist file into repo, which is rather a no go for java app. We could also split version of action and version of the app, then you'd pin to the yaml content with commit and action could use coursier to run based on version specified separately. I guess you'd also need to provide SHA for the main artifact, or ideally the whole tree. Anyway, I am not sure what is the best way to approach it, I am open to ideas.
@lukaszwawrzyk I have to admit that I'm actually not super "à jour" on the intrinsics of GitHub Actions...
... but they are basically container images, right? Can't it just contain the JAR?
It just "conceptually" seems strange to me that you have to DL it with cs to start with.
I also would not commit the binary dist file into repo, that's very ugly, I agree.
But during the build of the action (if there is a such a thing, I may be misunderstanding!) it could built & included?