Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dockerfile doesnt recognize key of env in secret mount #20935

Open
1 task done
Watts-Blake opened this issue Sep 19, 2024 · 6 comments
Open
1 task done

Dockerfile doesnt recognize key of env in secret mount #20935

Watts-Blake opened this issue Sep 19, 2024 · 6 comments
Labels
area/build Relates to Dockerfiles or docker build command status/triage Needs triage

Comments

@Watts-Blake
Copy link

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 Watts-Blake added the status/triage Needs triage label Sep 19, 2024
@Watts-Blake
Copy link
Author


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
Copy link

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
Copy link
Member

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;

@thaJeztah thaJeztah added the area/build Relates to Dockerfiles or docker build command label Sep 19, 2024
@Watts-Blake
Copy link
Author

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
Copy link
Member

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
Copy link

ktzsolt commented Oct 1, 2024

...
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build Relates to Dockerfiles or docker build command status/triage Needs triage
Projects
None yet
Development

No branches or pull requests

4 participants