Dockerfile doesnt recognize key of env in secret mount

[Watts-Blake]

Is this a docs issue?

• My issue is about the documentation content or website

Type of issue

Information is incorrect

Description

When dockerfile is ran in github action the an error is received saying key env is not recognized

Location

https://docs.docker.com/build/ci/github-actions/secrets/

Suggestion

No response

[Watts-Blake]

---

10 |
11 | >>> RUN --mount=type=secret,id=ALADTEC_CLIENT_ID,env=ALADTEC_CLIENT_ID
12 | >>> --mount=type=secret,id=ALADTEC_CLIENT_SECRET,env=ALADTEC_CLIENT_SECRET
13 | >>> --mount=type=secret,id=AZURE_AD_CLIENT_ID,env=AZURE_AD_CLIENT_ID
14 | >>> --mount=type=secret,id=AZURE_AD_CLIENT_SECRET,env=AZURE_AD_CLIENT_SECRET
15 | >>> --mount=type=secret,id=DATABASE_URL,env=DATABASE_URL
16 | >>> --mount=type=secret,id=NEXTAUTH_SECRET,env=NEXTAUTH_SECRET;
17 |

ERROR: failed to solve: unexpected key 'env' in 'env=ALADTEC_CLIENT_ID'

on below github action

    - name: 'Build and push image'
      uses: docker/build-push-action@v2
      with:
        context: .
        push: true
        tags: |
          ${{ secrets.ACR_REGISTRY_LOGIN_SERVER }}/test-the-daily:${{ github.sha }}
        build-args: |
          "NODE_ENV=production"
          "NEXTAUTH_URL="test"
          "NEXT_PUBLIC_VERSION: 0.0"
        secrets: |
          "ALADTEC_CLIENT_ID=${{ steps.getSecretsAction.outputs.ALADTEC-CLIENT-ID }}"
          "ALADTEC_CLIENT_SECRET=${{ steps.getSecretsAction.outputs.ALADTEC-CLIENT-SECRET }}"
          "AZURE_AD_CLIENT_ID=${{ steps.getSecretsAction.outputs.THE-DAILY-AAD-CLIENT-ID }}"
          "AZURE_AD_CLIENT_SECRET=${{ steps.getSecretsAction.outputs.THE-DAILY-AAD-CLIENT-SECRET }}"
          "DATABASE_URL=${{ steps.getSecretsAction.outputs.THE_DAILY_DATABASE_URL}}"
          "NEXTAUTH_SECRET=${{ steps.getSecretsAction.outputs.THE-DAILY-NEXTAUTH-SECRET }}"

[markmssd]

From the changelog, it's been added recently: https://docs.docker.com/build/buildkit/dockerfile-release-notes/#1100, maybe you need to update your version?

[thaJeztah]

As mentioned, this is a recent addition to the Dockerfile syntax, and (I think) GitHub actions still runs docker 26.1.

However, you can update the Dockerfile syntax by using a syntax directive; adding a # syntax directive as first line of your Dockerfile (generally recommended), will make sure you get the latest version;

# syntax=docker/dockerfile:1

FROM your-image
# etc..

See;

• https://docs.docker.com/reference/dockerfile/#syntax
• https://docs.docker.com/build/buildkit/frontend/

[Watts-Blake]

Thanks for the response both of you. Thats strange I was getting this error locally aswell and could of swore everything was up to date. I'll take some time tomorrow to test it out using the version syntax. Thanks again!

[thaJeztah]

Yes, so the documentation was updated when BuildKit did a release, and when it released the latest syntax (# syntax=docker/dockerfile:1.10.0). The version of BuildKit in Docker Engine 27.2.x was still using a version of BuildKit before that feature was introduced (Docker Engine 27.3.0 was released Yesterday and includes an updated version of BuildKit).

While some features require an update of BuildKit itself, other features (most notably; most changes in the Dockerfile syntax) do not; if you put a syntax directive in your Dockerfile, then Buildkit will download the syntax ("dockerfile frontend (parser)") before running the build. But if no syntax is defined, it will fall back to the default dockerfile syntax that corresponds with the version of BuildKit that's used (and thus may be an older version).

So in general, we recommend starting your Dockerfile with # syntax=docker/dockerfile:1, which means "latest v1.x.x" version; this means you'll always (*) get the latest stable version of the syntax (including bugfixes and new features). In some cases you may want to explicitly pin to a version, but this means "never update to e newer version", so it's for really specific use-cases.

(*); "always" may sometimes be after some days; the BuildKit team sometimes waits promoting the latest version to "latest"

[ktzsolt]

...
So in general, we recommend starting your Dockerfile with # syntax=docker/dockerfile:1, which means "latest v1.x.x" version; this means you'll always (*) get the latest stable version of the syntax (including bugfixes and new features).
...

This!
I started to use this feature as soon as it was available and was working fine until I started a new Dockerfile where I forgot to put in # syntax=docker/dockerfile:1 that I always do. I placed it at the beginning and voila, working.

Maybe dockerfile:1 should be the default when somebody uses buildkit (who doesn't nowdays?) with precedence order is first what is defined in the dockerfile, so one can override for labs version, like # syntax=docker/dockerfile:1.7-labs otherwise it is just noise in the Dockerfile.

[docker-robot]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[docker-robot]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked