GIT context ignores changes in build secrets and use GHA build cache from other build about build-push-action HOT 8 CLOSED

I can confirm this. Currently, it does not allow us to rotate credentials that we inject as build secrets without any further adjustments to the workflow being used.

from build-push-action.

I also tried to change path of dotenv file like

          secret-files: |
            "dotenv-file=.env.production"

but it was ignored as well and cache was used.

from build-push-action.

Yes, and even if the secret is part of GHA secret, the action is using cached secrets from other builds.

from build-push-action.

Build secret content does not participate in cache checksum calculation. This is to protect against leaking the value. If you want to invalidate cache when secret changes, add additional build arg (with a non-secret value) that you update same time that you update the secret value. The properties of the secret, eg. mount path, do participate in cache checksum.

Also, in GHA cache you can set the scope if you want to make sure that some builds do not share the same cache with others.

from build-push-action.

@tonistiigi Thanks for this answer. I did not know about this. Do you know if this is mentioned anywhere in documentation of action or in docker? Would be nice to have some mention about this.

I'll tried this trick with build arg and it works. I updated dockerfile:

FROM ubuntu

WORKDIR /app

COPY . .

ARG BUILD_ENV

RUN --mount=type=secret,id=dotenv-file,dst=.env \
   cp .env .env.production

and added changes in build jobs

      - name: Create dotenv
        run: echo "TEST=123" > .env

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          push: false
          load: true
          builder: ${{ steps.buildx.outputs.name }}
          tags: ${{ env.DOCKER_TAG }}
          build-args:
            BUILD_ENV=build-1
          file: Dockerfile
          provenance: false
          cache-from: type=gha,scope=secret-issue
          cache-to: type=gha,mode=max,scope=secret-issue
          secret-files: |
            "dotenv-file=.env"

But there is still irritating problem of changing build arg value when value of secret file changes. I could just use hash of contents of this file but since build args are left in build history then we go back to the original security issue of exposing checksum of secret file. I will probably need to introduce some encryption of this hash to make it secure or if possible use timestamp of last edit of this file or something like this.

Also based on observations of my private repo, where I encountered this, I noticed that this seems to happen only with GIT context. With path context it does not use cache at all when build secrets are involved. Are my observations correct?

Anyway, thanks for clearing this issue.

from build-push-action.

Also based on observations of my private repo, where I encountered this, I noticed that this seems to happen only with GIT context. With path context it does not use cache at all when build secrets are involved. Are my observations correct?

No, the context type does not change how secrets are cached. There might be some other reason why the cache gets invalidated when you use local paths that doesn't appear in git checkout (eg. nondeterministic checkout of .git directory).

from build-push-action.

Build secret content does not participate in cache checksum calculation. This is to protect against leaking the value. If you want to invalidate cache when secret changes, add additional build arg (with a non-secret value) that you update same time that you update the secret value. The properties of the secret, eg. mount path, do participate in cache checksum.

Also, in GHA cache you can set the scope if you want to make sure that some builds do not share the same cache with others.

Thanks for your reply, but I think I was not talking about GHA cache in particular, the scenarios was:

1. Clone a repo X to create new repo Y
2. Repo X had all the GHA vars secretes
3. Repo Y did not had any GHA vars or secrets
4. On Github Action workflow of repo Y, login to ECR action succussed even though there were no secrets defined for this repo in the GHA secrets, so I am not sure from where it picked the credentials, although it failed while pushing the image, so probably it picked some other credential which was valid but not applicable to the ECR repo I was pushing to.

So this is something which I can't understand unless there is a bug.

• docker/login-action@v3
• docker/build-push-action@v5, with push:true

Regards

from build-push-action.

@tonistiigi You are right again. I did some testing with dockerignore set like this:

*
!README.md

and it used cache in both jobs. Seems like some other action created files or updated them and they were not ignored in dockerignore file. Thanks for clarifying this. Now I just need to deal with dynamic build arg value generation when secret changes.

@edygyan Afaik cache is stored at the repo level and scoped to branches. Repository do not share cache with other repositories. To test what is going on you should probably do something similar as I did in my repo (piotrekkr/build-action-secret-issue#1)

1. simplify jobs and make two of them one depending on another
2. remove cache that is currently in repo to be sure that you start clean
3. run workflows and at the end run build images and display data that shuold not be cached to be sure if cache was used or not
4. also you can try ignoring all files by default in dockerignore and then include only directories and files you need for build (to exclude possible random files generated by other actions) or you can checkout code into subdirectory and use this subdir as context

from build-push-action.