Suggested improvements for image build and dependency management

[tigattack]

Hi, cheers for the image, this is great!

I have a few suggestions that could improve things, and would be happy to assist implementing them, but wanted to open a discussion first and hear your thoughts.

• Use docker/metadata-action to determine image tags, eliminating the need for a custom shell script in the workflow, and other metadata. You can see some examples of how I'm using it in a couple of slightly different ways here and here.
• Use Renovate to manage dependencies. This could be used to open PRs when there are updates to the base image, Photon dataset (though I see you already have a workflow for this), GitHub Actions dependencies, etc.
• Push to GitHub Container Registry as well as Docker Hub. Docker Hub has rate limits which can be quite limiting in some use cases, so GHCR is a nice alternative for many users. This can also be done very simply and examples can be seen at the links above where I've demonstrated use of docker/metadata-action.
• Use caching in the build step to improve build times & efficiency. This can be done as simply as this:

   - uses: docker/build-push-action@v6
     with:
       ...
       cache-from: type=gha
       cache-to: type=gha,mode=max

• Move ARG above RUN in the Dockerfile. This will help with cache efficiency and build times, since the RUN step's cache won't be invalidated every time the ARG value changes.

No worries at all if you don't wish to use any/all of these suggestions – I just wanted to offer some ideas. Thanks for all the work you’ve put into this!

[rtuszik]

Hi there!

I appreciate you taking the time to look at this repo :)

I opted for not using the docker/metadata-action because I wanted to peg my version numbers to the photon release versions, which is why I initially just took used that directly. This however wouldn't allow me to release updated versions of my image on GitHub, which is why I opted for the custom scripting which allows me to add revision suffixes to the version. If you have an idea of how to improve upon this, please do let me know!

As for Renovate - I am not very familiar with Renovate, but I am unsure as to how that would be better than a standard Dependabot setup (which I forgot to set up, thanks for the reminder 😁). If I were to track photon releases with Renovate it would not be much different from my script, right? Would love to hear your thoughts on what you think would be best here!

I had initially decided to not push to ghcr because they don't work with shields.io badges and I can't really track the pulls that way, but feel free to PR that change if you think it's an improvement!

As for the Dockerfile improvements, I'm very much on board. Let me know if you would like to PR. Otherwise, I'll implement those once I find the time :)

Thanks again.

[tigattack]

Re. metadata-action: You can use this in tandem with custom versions, for example I'm doing this in one of the examples above (see here). A nice benefit is that it will generate relevant OCI labels, annotations, etc. for the image to give a more complete picture of its origin.

Re. Renovate: In this case it may not be better, I just happen to be more familiar with it :) It's more flexible w.r.t. handling 'custom versioning', for example patching randomly placed strings in any old file with a regex manager. An example of that can actually be seen in another file in the same repo as linked above, here. But I digress, I think you're right that dependabot is the simplest option here. IMO Renovate would be a touch nicer, since it's "all in one" rather than a workflow for one thing and dependabot for others, but really I'm just nitpicking now 😄

Re. GHCR: That's frustrating, I didn't know it wasn't supported by shields.io. Perhaps you've seen, but it looks like there may be some viable options in the discussion in badges/shields#5594.

I shall PR a patch to the build/push workflow to push to GHCR, and to the Dockerfile as described before. I'll also see about adding metadata-action, ensuring your current versioning style is replicated, if you're on board with the idea.

[rtuszik]

Sounds good to me, looking forward to the PR.

As for shields.io badges, thanks for mentioning that thread. I'll look into it!