Bad context on version 6.x.x

[76creates]

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

I've found a bug, and:

• The documentation does not mention anything about my problem
• There are no open or closed issues that are related to my problem

Description

I have GH action where I update the .npmrc file to include authentication, this file is existing prior to me updating it and it contains placeholder info.

Example:
original . npmrc

foo:=_authToken=

updated . npmrc in step prior to build

foo:=_authToken=123

When I run build with . as a context, and use COPY . . the contents of the .npmrc within a build is original file as opposed to updated one.

Since I have used @master Ive tried with @v6.3.0 and @v5.13.0, it fails on 6 and passes with 5 version.

Expected behaviour

.npmrc contents are:

foo:=_authToken=123

Actual behaviour

.npmrc contents are:

foo:=_authToken=

Repository URL

No response

Workflow run URL

No response

YAML workflow

...
      - name: Update npmrc
        run: echo '//npm.pkg.github.com:_authToken=${{ secrets.GHRC_REPO_TOKEN }}' > .npmrc

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Login to GitHub Container Registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GHRC_REPO_TOKEN }}

      - name: Build and push
        env:
          IMAGE: ${{ env.IMAGE_NAME }}
          REPO: ${{ github.repository }}
          TAG: ${{ needs.opts.outputs.tag }}
          META_TAG: ${{ needs.opts.outputs.metaTag }}
        uses: docker/bake-action@v6.3.0
        with:
          targets: default
          push: false
...

Workflow logs

No response

BuildKit logs

Additional info

FROM node:18.20.4-alpine As builder

WORKDIR /app
COPY . .

# added to debug the issue
RUN cat .npmrc

RUN npm ci
RUN npm run build
RUN rm .npmrc

EXPOSE 3000
CMD [ "npm", "start" ]

[crazy-max]

When I run build with . as a context, and use COPY . . the contents of the .npmrc within a build is original file as opposed to updated one.

As stated in the release notes, Git context is used by default to build since v6: https://github.com/docker/bake-action/releases/tag/v6.0.0

As your Update npmrc step performs a file mutation it will be ignored as this is not part of the Git context, see docs: https://github.com/docker/bake-action?tab=readme-ov-file#git-context

Be careful because any file mutation in the steps that precede the build step will be ignored, including processing of the .dockerignore file since the context is based on the Git reference. However, you can use the Path context using the source input alongside the actions/checkout action to remove this restriction.

Not directly related but using COPY semantics to pass sensitive information is not recommended. You should use secrets for that purpose like https://github.com/docker/actions-toolkit/blob/da806c7a72fa83ee4caf06489c8b88c5c54bda84/docker-bake.hcl#L116 and then set the env in your workflow with the secret: https://github.com/docker/actions-toolkit/blob/da806c7a72fa83ee4caf06489c8b88c5c54bda84/.github/workflows/publish.yml#L24-L25.
Then your Dockerfile would just need to use this secret like so:

• https://github.com/docker/actions-toolkit/blob/da806c7a72fa83ee4caf06489c8b88c5c54bda84/dev.Dockerfile#L104
• https://github.com/docker/actions-toolkit/blob/da806c7a72fa83ee4caf06489c8b88c5c54bda84/dev.Dockerfile#L112

Of course it should not be done in the final stage if the image is exported but intermediate one that will just do the build to avoid leaking the token.

[GlitchDevX]

@crazy-max Just out of curiosity, why is the context git based? I feel like it's kind of a divergence from normal behavior when executing docker buildx bake via cli.

I spent a pretty long time trying to figure out why my build pipeline wasn't working and in the end I found this issue. I know that the build process should happen inside the docker file but in my case it unfortunately doesn't work.

[polarathene]

Just out of curiosity, why is the context git based?

Aligns with docker/metadata-action default.

Typically your project would have the default filename matched and in a CI pipeline you are getting the convenience of the git clone being done for you where the input is deterministic from the checkout.

Only when you need to manually introduce a file at an early stage prior to the build do you need to use the local path based context (which is typically more convenient for local iteration during development).

One kind (Path vs Git context) needs to be the default with the other opt-in, so perhaps that makes sense why Git is the default for automation with CI? Related actions likewise leverage the github provided workflow context, where you'll need to be more verbose with configuration if you deviate from the happy path 😅