Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determinism in image dependencies #4543

Open
bdovaz opened this issue Jan 19, 2025 · 10 comments
Open

Determinism in image dependencies #4543

bdovaz opened this issue Jan 19, 2025 · 10 comments
Labels
enhancement New feature or request

Comments

@bdovaz
Copy link
Collaborator

bdovaz commented Jan 19, 2025

Right now, there are many linters that do not have the version of the dependency to install and instead install the latest version available at that time.

This goes against the determinism, security, traceability, etc... Because if you generate the image right now or in 5 minutes you can get completely different versions of dependencies.

In this series of PRs I am trying to partly solve this problem:

#4528 #4529 #4530 #4531 #4532 #4533 #4534 #4535 #4536 #4537 #4538 #4539 #4540 #4541 #4542

I have focused on:

  • sh scripts that used the master/main branch.
  • Docker images using “latest”.
  • Dotnet dependencies with no version set.

Still a lot of npm, pip, etc.... This can be done in a next phase after merge all those PRs.

cc @nvuillam @echoix

@bdovaz bdovaz added the enhancement New feature or request label Jan 19, 2025
@nvuillam
Copy link
Member

This will bring us closer and closer to the "My Own MegaLinter Flavor" project :)

It will even allow "My Own MegaLinter Flavor with the linter versions I want" thing 🥳

@bdovaz
Copy link
Collaborator Author

bdovaz commented Jan 21, 2025

@nvuillam the remaining PRs related to this issue are ready for review and merge.

@bdovaz
Copy link
Collaborator Author

bdovaz commented Jan 21, 2025

Once this is done, we should go for the apk/npm/pip dependencies.

@bdovaz
Copy link
Collaborator Author

bdovaz commented Jan 26, 2025

I'm with the remaining packages (a lot of them): apk, cargo, gem, pip and npm.

@nvuillam it occurs to me that when we have all this we can on the page of each linter show with shields.io if the packages that each linter depends on are actively maintained, etc .... Just as we do with the linter itself.

I have encountered @echoix the following problem:

cli_docker_image: ghcr.io/realm/swiftlint

https://github.com/realm/SwiftLint/pkgs/container/swiftlint

Can you think how to make renovate update the tag? It would be necessary to create a custom manager or similar I guess, no? Right now by not putting the tag, it implicitly pulls latest...

@echoix
Copy link
Collaborator

echoix commented Jan 26, 2025

There's a cli_docker_image_version field available

self.cli_docker_image_version = "latest"

So now we only need to get that field updated. I searched on our GitHub repo for swiftlint, but I didn't see the image appear somewhere in the generated files.
If a variable could be substituted, we could have an "ENV " var in the Dockerfile, that could be kept updated from the descriptor and Dockerfile. Otherwise, it would be to create a regex/adjust a regex in the renovate config file to match what we need.

@bdovaz
Copy link
Collaborator Author

bdovaz commented Jan 27, 2025

PR created but I'm still working on it: #4588

I had to change in build.py how the “core” dependencies are added so that they are also versioned.

@nvuillam
Copy link
Member

@bdovaz i have a question and i'm afraid of the answer ^^

When we'll upgrade base image alpine version, we'll have all apk pinned to versions that do not exist in , so in my worst case scenario imagination:

  • renovate PR to upgrade alpine version will crash because core apk pinned versions won't be available in the alpine packages versions
  • it will generate dozens of PRs to upgrade ccore apk versions

Please can you reassure me ? ^^

I wonder it we shouldn't stick to linter versions in the first step, then see for the rest later, to make sure we don't have too much trouble

cc @echoix

@bdovaz
Copy link
Collaborator Author

bdovaz commented Jan 31, 2025

@nvuillam if you look at the releases history, they release 2 versions at most per year, I do not think that it's a problem or if for whatever reason we have to do some manual change in that PR we can.

https://alpinelinux.org/releases/

It would make me very unhappy after all the hours you've put in on this PR to have to undo something honestly.... I'd rather once or twice a year have to work on those Alpine version change PRs.

Actually whenever we upgrade Alpine or Python it is never easy and it always takes some time to make changes anyway.

@bdovaz
Copy link
Collaborator Author

bdovaz commented Jan 31, 2025

Also note that in renovate you can group packages by any criteria you want and one of them can be that the ecosystem is “repology”, that is, that all Alpine packages go in a single PR.

@nvuillam
Copy link
Member

If you can group alpine version and alpine packages in the same renovate-generated PR, ok for me :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants