Super-linter: Why does Versioning not work?

[bazzadp]

Describe the bug
There is a bug in v3.10.0 so I have not upgraded to this version so am still running 3.9.4.

I still hit the bug.

To Reproduce
Steps to reproduce the behavior:

1. Setup an action with node_modules and lock the version: uses: github/[email protected]
2. Lint a repo with a node_modules folder. Note this folder gets linted when it previously didn't

Expected behavior
Versions should lock the code for stability. It's pointless using version numbers if they are ignored and latest is always run.

Screenshots
Example run: https://github.com/HTTPArchive/almanac.httparchive.org/pull/1062/checks?check_run_id=1095951259
As can be seen it's running v3.9.4 but is showing the bug from 3.10.0

Additional context
This has been going on a while but annoyed me enough to raise a separate issue for this.

[zhenik]

I faced a similar issue. I would like to add a comment.

In the example run, the version setup is explicit, but logs show that version v3 is in use instead v3.9.4.

Setup version explicit

Log

Image taken with tag v3

Another example

https://github.com/fredrikhgrelland/terraform-nomad-presto/runs/1097023917?check_suite_focus=true

[admiralAwkbar]

@bazzadp I might need some help with the versioning code... seems it's not doing exactly what I would have expected

[bazzadp]

Happy to help test here. Other than that dunno how it works (or how it’s supposed to anyway!) so not sure I can help fix it.

[bazzadp]

Is there any chance of doing a 3.10.1 release while we wait for this to be resolved? #704 is causing us a lot of noise because of the combination of that and this bug. So I would rather get that fix out there with the existing "auto upgrade" and then fix this in a following release.

Worse case to me would be fixing this and then releasing both together, as then old branches from all our maintainers would be locked into the broken version, until they merged from main again and picked up the new version.

[ferrarimarco]

I think this is a duplicate of #655 (or related at least)

[bazzadp]

I think this is a duplicate of #655 (or related at least)

Possibly, but not convinced.

I'd expect the following to both be true:

1. Versions above v3.6.0 would fail
2. Locking to v3.6.0 would avoid any bugs introduced in v3.10.0

But neither is true.

[tbeaugrand]

@bazzadp I think the problem is due to the hardcoded version in action.yml file

image: 'docker://ghcr.io/github/super-linter:v3'

[bazzadp]

@tbeaugrand do you mean this action.yml file?

https://github.com/github/super-linter/blob/58d3d191b823648aeb2610568a29b31ee86e895d/action.yml#L5-L6

Because the syntax is slightly different than you gave.

[tbeaugrand]

@bazzadp yes sorry, i edited my post.

It was a copy from previous commit

[tbeaugrand]

@zkoppert why did you hardcoded this version ?

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[bazzadp]

Keep open please, unless explicitly planning not to support this, as I’d still like to explicitly lock the version and only upgrade when dependabot notifies me and gives me the choice. Especially given a few broken releases like those mentioned above.

[bazzadp]

I see we've released another bug in #938 breaking all linting on anyone using this project. Can we please look at this issue and introduce proper versioning to avoid this?

[dec5e]

I've proposed a fix for described issue in #947.

[dec5e]

I've proposed a fix for described issue in #947.

This proposed solution doesn't work. It seems at the moment the only option to fix versioning is to have versioned action.yaml with hardcoded image tag

[dec5e]

@admiralAwkbar Could you put more attention to this issue? It's really important to have an option to use specific super-linter version without "workarounds". There was recently the "outage" for super-linter because of #938 and the only option to fix it was to switch to docker image with locked tag. That shouldn't be a recommended way.

It seems there is no simple way to make versioning work. In my PR #947 I tried to omit docker tag, expecting action's version to be passed to the image as an image tag but that didn't work.

And as said the same PR: it would be nice if super-linter and Actions teams inside Github will join forces and find a good way to fix versioning for this [and other docker] actions. As I see it, ideal solution would automatically pass action's version as docker tag with simple syntax or even automatically. Don't know how difficult is this if possible at all. Other option I see requires building an automated workflow of updating action.yaml with hardcoded docker tag before publishing a new action's versions.

[admiralAwkbar]

@dec5e Hey! I agree... it has been hard to get some time on this issue but I will try to find some internal help at GitHub from the Actions team and see if there is something better we can be doing.

Sorry for the outages that have been caused, we're working on more testing and better vetting of the source.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[bazzadp]

Please keep open

[ahmadnassri]

@admiralAwkbar curious if you've heard from anybody within GitHub about this? also happy new year!

[admiralAwkbar]

@ahmadnassri We updated the build process before break and I'm wondering if this has fixed the issue?

can you try to see if all is working as expected now?

[ahmadnassri]

@admiralAwkbar the linting issue which resulted in the errors at the time is fixed yes, however I'm still curious about Docker based Actions versioning ... not being able to use a "fixed" version is still a problem!

[ahmadnassri]

Linking to #490 as well

[zkoppert]

consolidating this issue into #490. Let's continue the discussion there.