oxsecurity
Move GitHub Action image to GitHub Packages
Is your feature request related to a problem? Please describe.
It would be great to load the image from GitHub Packages, as I assume this will be a substantially faster pulling experience.
https://github.com/megalinter/megalinter/blob/0126180f621bdb4f84b1864e6788daba8c7b1642/action.yml#L10
Describe the solution you'd like
- Upload said image to GitHub Packages
- Use it in
action.yml
We would probably need to offer the image via both Docker and GitHub Packages at least for now since it seems like a pretty breaking change. I may be missing something since I have never used GitHub Packages, but If you or anyone else finds time to open a pull request, it seems like a low-effort, high-reward way to boost pull performance for GitHub users without affecting others.
In the meantime, those using GitHub Actions might try the dirt simple docker-cache action I wrote to improve our MegaLinter pull times.
@Kurt-von-Laven Seems like this is already in place, not sure why its not executed:
https://github.com/megalinter/megalinter/blob/f958756b80b7a1bbc8b0115abf80a53a55ee1c70/.github/workflows/deploy-PROD.yml#L94-L104
Oh, maybe my assumption that we don’t already do this was wrong in that case. I do notice a few errors in the logs about some Docker images not being found, but they do claim a successful upload to the GitHub Container Registry. I am unfamiliar with all of these tools and on mobile right now, so please let me know if I am overlooking the obvious.
The main docker image is uploaded to github registry, but not the flavor images yet
I think this was because github registry allowed only one image name by repo but maybe that changed, i can have a look
I read this blog post to say that they now allow multiple images per repo:
It's great that the
<repo-name>above does not have to be a git repository name. The Container registry namespace is now separate from the git repository namespace — you can push images into container repositories with names likeorg/x1andorg/x2using code from a GitHub repo named something completely different (e.g.org/something-else). In my opinion, this is a really nice change and aligns much more effectively with how teams use these registry products.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
What needs to happen to move this forward? Seems like an easy win for a speed boost?
MegaLinter as a whole is feature frozen for the next week or so to get v6 released.
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.
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.
It sounds like this is a matter of adding a section similar to this one to deploy-RELEASE-flavors.yml then? Would it also make sense to update mega-linter-runner to support pulling from GHCR?
Yes, we would need first to also store flavor images on GHCR, then update the action.yml files to target it About MegaLinter runner, as it can be called from anywhere i prefer to let it on docker by default, but we could add an option --registry to allow to target ghrc
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.
Quick question...
Without getting too much into the backstory, we're looking at pulling from GHCR instead of DockerHub to cut down on the load time for Megalinter runs. With that in mind, when I try to pull from GHCR without authenticating first, I get a permissions error:
$ docker pull "ghcr.io/oxsecurity/megalinter-ci_light:v7.10.0"
Error response from daemon: Head "https://ghcr.io/v2/oxsecurity/megalinter-ci_light/manifests/v7.10.0": denied: denied
However, when I authenticate first (i.e., docker login ghcr.io), I can pull that image just fine.
In my past experience, that generally happens when I leave an image marked as private (i.e., I don't mark it as public).
So, question is, "is that what's happening here? if so, is that intentional?"
The workaround for us is to authenticate first before running Megalinter (e.g., https://github.com/oxsecurity/megalinter/blob/main/.github/workflows/deploy-RELEASE-flavors.yml#L85-L90 ) when running an Action.. just curious if what we're seeing is intentional or not.
Thanks for reporting @wesley-dean-flexion
Hmm if the images are private, it's not on purpose :/
In the settings it's flagged as public... I have no idea why we have to be logged :/