Using Private Dockerhub & Attempting to change Github Actions vars.repository value doesn't result in changes?

[g7morris]

Hi @nigelgbanks

I'm attempting to build Docker images from our own forked isle-buildkit project that will push to our own private Dockerhub registry.

• When I review this https://github.com/Islandora-Devops/isle-buildkit/blob/main/.github/workflows/push.yml#L26 there is a reference to repository: ${{ vars.repository }} yet when I attempt to override this value in Github ala

I'm still pushing the base image to the islandora Dockerhub registry which isn't ideal.

• I also see this https://github.com/Islandora-Devops/isle-buildkit/blob/main/.env#L31 which I don't want to edit each time (from islandora to born-digital) each time I make a isle-buildkit maintainer's PR to this upstream project. Right?
  • Should I be able to leave this value as islandora in the file but "override" the value in my forked Github git repo Variables / Secrets?
    • If yes, then shouldn't my change above "work"?
    • If no, then are we missing something possibly like an extra line here https://github.com/Islandora-Devops/isle-buildkit/blob/main/.github/workflows/build.yml#L50 to allow for a change in registries or repositories?

Did I miss any isle-buildkit documentation on how folks can do this but still stay at parity with isle-buildkit when submitting changes or do we need to build the ability to switch to non-Islandora repos and registries?

Thanks!

[g7morris]

I'll note that it appears even if I edit the .env file in the codebase, new images are run and pushed to the islandora Dockerhub.

I also note that https://github.com/Islandora-Devops/isle-buildkit/blob/main/.github/workflows/description.yml#L26 seems to have hardcoded values too? Do we want to change this to a variable instead?

[nigelgbanks]

We could change it such that REPOSITORY is set before calling make in

isle-buildkit/.github/workflows/build.yml

Line 56 in 171ae20

make push manifest "PROGRESS=plain" "BUILDER=${{ steps.buildx.outputs.name }}" "TARGET=${{ inputs.image }}-ci" "TAGS=${{ inputs.tags }}" "CONTEXTS=${{ inputs.contexts }}"

.

Also, for the descriptions, we could use the ${{ vars.repository }}.

Which I think covers the bases.

Though I'd probably say doing a fork is probably a waste of time. If you need to do customizations, extend the existing images and modify them. Your build times will be significantly faster, you'll have less code to maintain, and upgrades will be easier.

[g7morris]

Ah fair play. It would be nice to see those changes go in though just in case. Is that something you can push please?

In the meantime, I appreciate your comment here:

If you need to do customizations, extend the existing images and modify them

I'll start focusing on that route and see what dividends pay out. Cheers @nigelgbanks !

[nigelgbanks]

Oh yeah, these changes can go through. I'll push something up now.

[nigelgbanks]

#316

[nigelgbanks]

@g7morris rebase from main and let me know if the recent changes sort the issue for you.

[g7morris]

Thank you!