Giter VIP home page Giter VIP logo

docker-build-with-cache-action's Introduction

Docker build-with-cache action

This action builds your docker image and caches the stages (supports multi-stage builds) to improve building times in subsequent builds.

By default, it pushes the image with all the stages to a registry (needs username and password), but you can disable this feature by setting push_image_and_stages to false.

Built-in support for the most known registries:

  • Docker Hub
  • AWS ECR (private and public)
  • GitHub's (old and new registry)
  • Google Cloud's (currently not under test)

๐ŸŒŸ Action supercharged

  • Docker updated to 24.0.6

  • BuildKit is enabled for faster/parallel builds

  • Cache also works with BuildKit enabled except for old GitHub Docker Registry (docker.pkg.github.com). You can either migrate to ghcr.io or disable BuildKit to use the old registry:

    - name: Build with DOCKER_BUILDKIT disabled for old GitHub Docker Registry
      uses: whoan/docker-build-with-cache-action@master
      env:
        DOCKER_BUILDKIT: 0
      with:
        registry: docker.pkg.github.com
      ...
    

Inputs

Required

  • image_name: Image name (e.g. node).

or

  • compose_file: path to Docker Compose file. You will need to configure this action multiple times if you have a compose file which uses more than one registry.

๐ŸŒŸ New in v5.10.0: Now you can use overrides for your compose file(s) like this:
docker-compose.yml > docker-compose.override.yml > docker-compose.override2.yml

Optional

  • image_tag: Tag(s) of the image. Allows multiple comma-separated tags (e.g. one,another) (default: latest).
    If you set compose_file and the image(s) already has/have a tag, this is ignored.

  • context: Docker context (default: ./). If a compose_file is provided, it will be the context prefixed to any additional context read from the compose file. Look at #133 for more details.

  • registry: Docker registry (default: Docker Hub's registry). You need a registry to use the cache functionality.

  • username: Docker registry's user (needed to push images, or to pull from a private repository).

  • password: Docker registry's password (needed to push images, or to pull from a private repository).

  • session: Extra auth parameters. For AWS ECR, means setting AWS_SESSION_TOKEN environment variable.

  • push_git_tag: In addition to image_tag, you can also push the git tag in your branch tip (default: false).

  • pull_image_and_stages: Set to false to avoid pulling from the registry or to build from scratch (default: true).

  • stages_image_name: Set custom name for stages/cache image (default: ${image_name}-stages). Tags are ignored.

  • push_image_and_stages: Test a command before pushing. Use false to not push at all (default: true).

    This input also supports 2 special values, which are useful if your workflow can be triggered by different events:

    • on:push: Push only if the workflow was triggered by a push.
    • on:pull_request: Push only if the workflow was triggered by a pull_request.
  • services_regex: Regex to filter services from compose file. Only valid when compose_file was provided. Default is .+ (all services).

Ignored if compose_file is set

  • image_name

  • dockerfile: Dockerfile filename path (default: "$context"/Dockerfile).

  • build_extra_args: Extra params for docker build (e.g. "--build-arg=hello=world").

    ๐ŸŒŸ New in v5.11.0: If you need extra args with newlines or spaces, use json format like this:
    build_extra_args: '{"--build-arg": "myarg=Hello\nWorld"}'

    ๐ŸŒŸ If you need multiple args with same key, use an array as the value of the key like this:
    build_extra_args: '{"--build-arg": ["foo=bar", "one=two"]}'

Outputs

  • FULL_IMAGE_NAME: Full name of the Docker Image with the Registry (if provided) and Namespace included.
    e.g.: docker.pkg.github.com/whoan/hello-world/hello-world

How it works

The action does the following every time it is triggered:

  • (Optional) Pull previously pushed stages (if any) from the specified registry (default: https://hub.docker.com)
  • Build the image using cache (i.e. the pulled stages)
  • Tag the image
  • (Optional) Push the image with the tag(s) specified in image_tag
  • (Optional) Push each stage to the registry with names like <image_name>-stages:<1,2,3,...>
  • (Optional) Push the git tag as <image_name>:<git_tag> if you set push_git_tag: true

Examples

Find working minimal examples for the most known registries in this repo.

Docker Hub

If you don't specify a registry, Docker Hub is the default one

- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: whoan
    password: "${{ secrets.DOCKER_HUB_PASSWORD }}"
    image_name: hello-world

GitHub Registry

GitHub automatically creates a GITHUB_TOKEN secret to use in your workflow. If you are going to use the new GitHub Registry (ghcr.io), be sure to use a Personal Access Token (as the password) with "write:packages" and "read:packages" scopes. More info here.

If you push the image to a public repository's GitHub Registry, please be aware that it will be impossible to delete it because of GitHub's policy (see Deleting a package).

- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: whoan
    password: "${{ secrets.GITHUB_TOKEN }}"
    registry: docker.pkg.github.com
    #or
    #registry: ghcr.io
    image_name: hello-world

Google Cloud Registry

More info here on how to get GCloud JSON key.

- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: _json_key
    password: "${{ secrets.GCLOUD_JSON_KEY }}"
    registry: gcr.io
    image_name: hello-world

AWS ECR

You don't even need to create the repositories in advance, as this action takes care of that for you! (you'll need the CreateRepository permission)

- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: "${{ secrets.AWS_ACCESS_KEY_ID }}"  # no need to provide it if you already logged in with aws-actions/configure-aws-credentials
    password: "${{ secrets.AWS_SECRET_ACCESS_KEY }}"  # no need to provide it if you already logged in with aws-actions/configure-aws-credentials
    session:  "${{ secrets.AWS_SESSION_TOKEN }}"  # if you need role assumption. no need to provide it if you already logged in with aws-actions/configure-aws-credentials
    # private registry
    registry: 861729690598.dkr.ecr.us-west-1.amazonaws.com
    # or public registry
    #registry: public.ecr.aws
    image_name: hello-world

From a compose file

The compose file is parsed and the action will run once for each detected image. The registry is also detected from the image name, and if none is provided, DockerHub is assumed.

- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: whoan
    password: "${{ secrets.DOCKER_HUB_PASSWORD }}"
    compose_file: docker-compose.yml
- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: whoan
    password: "${{ secrets.GITHUB_TOKEN }}"
    registry: docker.pkg.github.com
    compose_file: docker-compose.yml

With a compose file override:

- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: whoan
    password: "${{ secrets.DOCKER_HUB_PASSWORD }}"
    compose_file: docker-compose.yml > docker-compose.override.yml

Filtering services by regex:

- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: whoan
    password: "${{ secrets.GITHUB_TOKEN }}"
    registry: docker.pkg.github.com
    compose_file: docker-compose.yml
    services_regex: '(service_1|extra_service.*)' # eg: builds services called exactly "service_1" plus the ones which start with "extra_service" and may have extra chars after

Example with more options

- uses: whoan/docker-build-with-cache-action@v5
  with:
    username: whoan
    password: "${{ secrets.GITHUB_TOKEN }}"
    image_name: whoan/docker-images/node
    image_tag: alpine-slim,another-tag,latest
    push_git_tag: true
    registry: docker.pkg.github.com
    context: node-alpine-slim
    dockerfile: custom.Dockerfile
    build_extra_args: "--compress=true --build-arg=hello=world"
    push_image_and_stages: docker run my_awesome_image:latest  # eg: push only if docker run succeed

Cache is not working?

  • Be specific with the base images. e.g.: if you start from an image with the latest tag, it may download different versions when the action is triggered, and it will invalidate the cache.
  • If you are using Buildkit, the stages won't be pushed to the registry. This might be supported in a future version.
  • Some docker limitations might cause the cache not to be used correctly. More information in this SO answer.

Tests

The tests for this action are run in a separate repo as I need to set credentials for each registry with GitHub secrets and doing so in this repo is not practical.

License

MIT

docker-build-with-cache-action's People

Contributors

asbjornu avatar bubenkoff avatar eltimn avatar fabio-d avatar gabe565 avatar grosquildu avatar isdelrey avatar joni2back avatar jsoref avatar nullableint avatar scottbrenner avatar whoan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

docker-build-with-cache-action's Issues

Action Step "Pulling Image" works locally in act, but not in action

Hi, this action seems to do exactly what I want. And it works via act, but when I run it in github, the "Pulling Image" step seems to be skipped. Am I doing something wrong?

Here's my stanza

      - name: Build Rails Image
        uses: whoan/docker-build-with-cache-action@v5
        with:
          username: '${{ secrets.AWS_ACCESS_KEY_ID }}'
          password: '${{ secrets.AWS_SECRET_ACCESS_KEY }}'
          registry: xxx.dkr.ecr.us-west-2.amazonaws.com
          dockerfile: Dockerfile.phusion
          image_name: app-delete_me
          push_git_tag: true
          image_tag: 'latest,${{ github.run_number }}'
          pull_image_and_stages: true
          push_image_and_stages: true

In act (locally) the image pulls work

[Build/app_ecs] โญ  Run Build Rails Image
[Build/app_ecs]   โ˜  git clone 'https://github.com/whoan/docker-build-with-cache-action' # ref=v5
[Build/app_ecs]   ๐Ÿณ  docker build -t act-whoan-docker-build-with-cache-action-v5:latest /Users/timothysabat1/.cache/act/whoan-docker-build-with-cache-action@v5
[Build/app_ecs]   ๐Ÿณ  docker run image=act-whoan-docker-build-with-cache-action-v5:latest entrypoint=[] cmd=[]
| 
| [Action Step] Checking required input...
| 
| [Action Step] Log in to registry...
| WARNING! Your password will be stored unencrypted in /github/home/.docker/config.json.
| Configure a credential helper to remove this warning. See
| https://docs.docker.com/engine/reference/commandline/login/#credentials-store
| 
| Login Succeeded
| 
| 
| 
| [Action Step] Pulling image...
| 1: Pulling from app-delete_me-stages
| Digest: sha256:1b11a839f3bae988aaa7a467eebe63a3941b51db01233178e8efe8f290633a02
| 2: Pulling from app-delete_me-stages
| Digest: sha256:ad7097c938d2c0d2911803c5dfff38e3b143ad38e16997abad5747b4985e94f6
| 3: Pulling from app-delete_me-stages
| Digest: sha256:81f9625ab3b8b38d3545270817023334d41eaabc1975ae8c26a7602250f92794
| Status: Image is up to date for xxx.dkr.ecr.us-west-2.amazonaws.com/app-delete_me-stages
| xxx.dkr.ecr.us-west-2.amazonaws.com/app-delete_me-stages
| 
| [Action Step] Building image...

But when I run this in github, the image pull process seems not to happen.

Screen Shot 2020-08-14 at 12 10 19

Document several limitations

Hi, i'm trying to migrate one of our Docker builds to Github Actions and would like to use Docker caching features to improve our build times.

We currently have a fat Multi-stage Dockerfile with 9 stages, I encountered several limitations and think those should be documented in the project (unless somebody found workaround to prevent those limitations).

Here are what I propose to be documented.

First limitation

Our current setup is using Buildkit (enabled through the DOCKER_BUILDKIT environment variables) with experimental features (enabled by passing --experimental to command used to start the Docker daemon).

When Buildkit is enabled the Docker build-with-cache action cannot work because the Docker build output is different with and without Buildkit.

Without Buildkit the output contains Step X/Y : FROM ... lines which can them be parsed by the _get_stages() Bash function.

With Buildkit those lines are not their.

Second limitation

When we read the Docker build-with-cache action README.md we believe that caching should work in all cases without any problem.

I think its not the case because of the limits documented in this StackOverflow comment https://stackoverflow.com/questions/54574821/docker-build-not-using-cache-when-copying-gemfile-while-using-cache-from/56024061#56024061

So, the order of the --cache-from instruction matters but in the project the current order in use is simply {1..$max_stage} (see it in the build_image() Bash function). With our 9 stages I tried to manually change the order but I think their are simply no solution to find ONE good order which will lead to using cache everywhere / in all stages ๐Ÿ˜ž .

Do you agree with those 2 limitations and to document them inside the README.md file of the project ?

If not do you have a solution to make caching really work with our 9 stages Multi-stage Docker build ?

Image is not pushed if `on:push` is disabled

I have a scheduled workflow:

on:
  schedule:
    - cron:  '0 4 * * *'

When the workflow runs, the image is built but not pushed.Here a log:

[Action Step] Pushing image...
Not pushing

I guess it's _must_push function returning false:

_must_push() {
  if [ "$INPUT_PUSH_IMAGE_AND_STAGES" = on:push ]; then
    [ "$GITHUB_EVENT_NAME" = push ]
    return
  fi

  if [ "$INPUT_PUSH_IMAGE_AND_STAGES" = on:pull_request ]; then
    [ "$GITHUB_EVENT_NAME" = pull_request ]
    return
  fi

  $INPUT_PUSH_IMAGE_AND_STAGES
}

Is this the expected behavior? I find it confusing.

New to Docker, a few questions

Howdy! I have a few questions about this tool. I'm newer to Docker, so please bear with me and forgive me if I'm not clear or asking an obvious question.

  • If I don't use a multi-stage build, are my images cached?
  • If I have push_image_and_stages: false, are my images cached?
  • If I have push_image_and_stages: false and no credentials for a registry, are my images cached?
  • If I'm using images that I don't own on Docker Hub, I get this error:
The push refers to repository [docker.io/hexpm/elixir]
...
denied: requested access to the resource is denied

Do I have to have to be pulling images from repos that I own for my images to be cached?

Thank you in advance!

Multiple tags not working?

I've setup my config to push multiple tags on subsequent builds:

name: Docker Image CI

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:

  build:

    runs-on: ubuntu-latest

    steps:
      - name: 'Checkout GitHub Action'
        uses: actions/checkout@v2
      - name: Build and push docker
        uses: whoan/docker-build-with-cache-action@v5
        with:
          username: ${{ secrets.GH_PACKAGES_USER }}
          password: ${{ secrets.GH_PACKAGES_TOKEN }}
          registry: docker.pkg.github.com
          image_name: ${{ github.repository_owner }}/${{ github.event.repository.name }}/${{ github.event.repository.name }}
          image_tag: latest,${{ github.sha }}

But it appears that the "latest" tag doesn't ever update. New builds push out with the new github sha. Am I missing something?

Run container before publishing

This looks like a neat action, but I would like to test that the built container works before publishing it. Would it be possible to do docker run and only publish if that succeeds?

support aws-actions

you should be able to login to aws ecr using the official actions like this.

      - uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.ECR_AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.ECR_AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      - uses: aws-actions/amazon-ecr-login@v1
        id: login-ecr

Cache with matrix builds

There should be a way to specify the cache repository name.
I'm trying to build this and only one gets cached

  postgres:
    strategy:
      matrix:
        version: ['9.5', '9.6', '10', '11', '12']
    needs: primary
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v2
    - name: Build and push to Docker Hub
      uses: whoan/docker-build-with-cache-action@v5
      with:
        image_name: ${{ github.repository_owner }}/ledgersmb_circleci-postgres
        image_tag: ${{ matrix.version }}
        build_extra_args: "--build-arg postgres=${{ matrix.version }}"
        push_git_tag: true
        context: postgres

It could default to the current value but the user should be able to specify it.

Does this work with services?

I have a postgres server that's initialised like this in the yaml file:

jobs:
  build:

    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:12.1
        env:
          POSTGRES_USER: postgres
          POSTGRES_DB: postgres

Is it possible to cache this, and if so, how?

Clarification on cache location

Hello! I've started using this action but I've been left slightly confused as to it's purpose and how it actually functions and was just wondering if you could clarify a few points for me please?

I'm mainly confused as to the cache location that is being used for the Docker images - is it using the Github repository cache? Or is it using the docker-stages images that get created when this action is run to cache the build stages? I'm using this on a fairly simple image where the bulk of the build time is from download of the initial FROM: statement. If the answer previous question is that the stages are cached in the Docker repository, I assume that means that I will not see any meaningful speed improvements from using this action?

Thank you!

Could not set namespace

Hello!

just wanted to know if I have to change something after the latest changes in the parsing of the namespace.
For me personally the action worked before this change, but now I get 'Could not set namespace' on each build.

Context: I have a registry on gcr and I try to build images with custom tags

Hints and Tips would be appreciated.

401 Unauthorized

Error response from daemon: login attempt to https://***/v2/ failed with status: 401 Unauthorized

I've went ahead and ran the commands in entrypoint.sh manually to ensure that the credentials are valid. They are fine.

Evaluation of the registry endpoint succeeds in determining that it is an ECR endpoint, so I should be falling into the right docker login with aws ecr.

Not sure where else to look.

Please warn that GitHub Registry public packages cannot be removed/replaced

Hello,
thanks for your effort in implementing this much needed action.

I have used it with GitHub's registry in a private test repository, and it worked.
However, when I tried to use it in a public repository, I was disappointed to find that it is impossible to neither update nor delete the cache. Not because of a bug of this action, but as a result of GitHub's controversial "immutable public registry policy":

To avoid breaking projects that may depend on your packages, you cannot delete an entire public package or specific versions of a public package.

The result of this hidden "trap" is that my public repository now has two old stale images, no longer even useful for the CI workflow, but they still appear prominently in the project's main page with no way to hide/delete them.

I suggest to add a notice in this action's readme file, to warn potential users like me about this pitfall. Something along the lines of

If you are considering pushing the image to a public repository's GitHub Registry, please be aware that it will be impossible to ever delete or even update/rebuild the cache after the first run of this action, because of GitHub's policy regarding public packages. In other words, the cache will be immutable and not deletable. This limitation does not apply if the image is pushed to a private repository's GitHub Registry. For more information, refer to GitHub's Help about Deleting a package.

unable to prepare context, Dockerfile not found

I'm trying this action out in PX4/PX4-containers#225 but it doesn't seem to find the context and Dockerfile:

unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /github/workspace/Dockerfile: no such file or directory

I started off with a context and a non-default Dockerfile but moved to all defaults now and it is still not working. What am I doing wrong? Have some paths changed?

Thanks!

Push git tag automatically if available

Currently, the action pushes the image with the image tag specified in image_tag or latest by default.

I think it would be fine to push an image with a tag equal to the git tag.

image name/tag not working

Passing an image name and tag is not working.

      - name: Build and Cache Develop Image
        uses: whoan/docker-build-with-cache-action@v4
        with:
          registry: ${{ env.DOCKER_REGISTRY }}
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
          dockerfile: base.dockerfile
          context: .docker
          image_name: nodebrick/nodebrick-develop
          image_tag: ${{ env.DEBIAN_VERSION }}-${{ env.NODE_VERSION }}
          push_image_and_stages: false
          build_extra_args: "--build-arg PROJECT_ID=${{ env.PROJECT_ID }} --build-arg DEBIAN_VERSION=${{ env.DEBIAN_VERSION }} --build-arg NODE_VERSION=${{ env.NODE_VERSION }}"

Logs

[Action Step] Building image...
+ docker build --tag my_awesome_image --file .docker/base.dockerfile --build-arg PROJECT_ID=nodebrick --build-arg DEBIAN_VERSION=buster-slim --build-arg NODE_VERSION=current .docker

Action can be seen in action here
https://github.com/nodebrick/nodebrick/runs/502276509?check_suite_focus=true

Workaround is adding the --tag arg in the build_extra_args
--tag ${{ env.DOCKER_REGISTRY }}/${{ env.DOCKER_REPOSITORY }}-develop:${{ env.DEBIAN_VERSION }}-${{ env.NODE_VERSION }}

COPY command results seem to get cached

Strangely we don't see our new source code being copied over the cached version when building. What could be going on? This has started about a month ago, and we have not changed our Dockerfile nor our GitHub workflow pipeline.

Our pipeline invocation of the plugin:

      - name: CI tests, image build and push tag for master or branch
        uses: whoan/docker-build-with-cache-action@v5
        with:
          username: redkubesbot
          password: '${{ secrets.NPM_TOKEN }}'
          registry: ${{ env.CACHE_REGISTRY }}
          image_name: ${{ env.CACHE_REPO }}
          image_tag: ${{ env.TAG }}

And our Dockerfile:

FROM node:14-slim as npm

ENV APP_HOME=/home/app/stack
RUN mkdir -p $APP_HOME
WORKDIR $APP_HOME

ARG SKIP_TESTS='false'
ENV CI=true

COPY . .
COPY ./.cspell.json .

RUN if [ "$SKIP_TESTS" = 'false' ]; then \
  npm install cspell && npm run spellcheck; fi

#-----------------------------
FROM otomi/tools:1.4.10 as test

ENV APP_HOME=/home/app/stack
RUN mkdir -p $APP_HOME
WORKDIR $APP_HOME

ARG SKIP_TESTS='false'
ENV CI=true

COPY . .

RUN if [ "$SKIP_TESTS" = 'false' ]; then \
  cp -r .demo/ env/ && \
  bin/validate-values.sh && \
  bin/validate-templates.sh && \
  bats bin/tests; fi

#-----------------------------
FROM otomi/tools:1.4.10 as prod

ENV APP_HOME=/home/app/stack
RUN mkdir -p $APP_HOME
WORKDIR $APP_HOME

COPY . .

CMD ["bin/otomi"]

Disable pull option

Cool actions, thanks for it.

But I wonder if there is option to build and push images without pulling them first from the repo? For one action run of course, just to rebuild images from scratch. Question due to the problem of running out of memory when both pulling old images and rebuilding new.

And I can't clear the registry manually, but why is a longs story ;)

Support for AWS ECR public registry

Hello!

Thanks for this nice action. Following #27, would it be possible to support AWS ECR public registry? This has been launched in December 2020.

The relevant documentation is here: https://docs.aws.amazon.com/AmazonECR/latest/public/public-registries.html#public-registry-auth

The auth command is

aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws

I think what's needed is:

  • updating the regex to match the public endpoint (or create a new detection mechanism)
  • bump the AWS CLI to be able to use the ecr-public namespace

Use new GitHub Container Registry

GitHub has released a second Registry, which currently is still in beta and only supports Docker images for now. See official Migration Guide for details.

I have tried pushing to it but ran into a timeout. Here's my workflow file (trimmed version):

    - name: Build
      uses: whoan/docker-build-with-cache-action@v5
      with:
        image_name: my-image-name
        username: my-user-name
        registry: ghcr.io
        password: "${{ secrets.GHCR_TOKEN }}"

In the workflow logs I spotted this message: The push refers to repository [ghcr.io/hetzner-dyndns]. Looks like my username my-user-name is ignored.

Release Stability

Hi,

our builds failed because of breaking changes in docker-build-with-cache-action@v4. I narrowed the version to [email protected]. This worked fine yesterday, but today this release is gone.

As we require to have stable builds it would be nice, if there would be stable released versions.

COPY commands cached as well?

Is it expected that stages with the COPY command (IE: COPY ./ ./) will be cached as well?

My newly committed file changes were being ignored in new image builds.

Cannot be used for CI from forked repos

This action requires a username and password to be used. However, GitHub actions does not support accessing secrets when building PRs from a fork. Therefore this action will fail to be used as a PR status check.

Since the password is only used for publishing to the cache is it possible to add support for just downloading and building from cache. Then the password would at least not be needed?

Add support for build-args

Currently passing --build-arg to the Docker call is not supported, but I could see that being a commonly used feature.

Are there any plans to add support for build-args? I can take a look soon.

Use to precache container actions?

Hello,

I have this working and it downloads and works with cached images just fine using docker.
However, it appears for whatever reason the images don't stay cached on the runner, so when I try to run an image that uses the same dockerfile, it doesn't pull from cache and builds again.

Here is the example:
https://github.com/JustinGrote/Super-Duper-Linter/actions/runs/143165760/workflow
https://github.com/JustinGrote/Super-Duper-Linter/runs/793939119?check_suite_focus=true

Cannot login to ECR

When I try to use your action against the AWS registry (ECR) I get this message:

Error response from daemon: login attempt to https://***.dkr.ecr.eu-central-1.amazonaws.com/v2/ failed with status: 401 Unauthorized

Do you have any running example with AWS? Or is there something than prevents this action to work with it?

Follows my configuration:
- uses: whoan/docker-build-with-cache-action@v3
with:
username: ${{ secrets.AWS_ACCESS_KEY_ID }}
password: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
image_name: XXXXXXXXX.dkr.ecr.eu-west-1.amazonaws.com/repo-name
image_tag: dev
registry: XXXXXXXXX.dkr.ecr.eu-west-1.amazonaws.com
context: repo-name

Cache not working

I created a Dockerfile with 3 stages, successfully built and pushed to the Github registry inside a Github action, but at the next run, without having invalidated any of the first layers (tested locally), the build started from scratch.

How does it work? Did I do something wrong?

Proplems with mixed case github usernames

Hi :) thank you for this action.

I'm getting an error during pushing. It seems like the repository name has to be lowercase and my github username is not lowercase and this is causing an issue:

Error parsing reference: "docker.pkg.github.com/..." is not a valid repository/tag: invalid reference format: repository name must be lowercase

I guess the issue is here: https://github.com/whoan/docker-build-with-cache-action/blob/master/entrypoint.sh#L67. It should lowercase the string.

Multi-Platform Docker Builds

Currently, I did not find any settings or variables that could be used to trigger multi-platform Docker builds.

With M1 MBPs, arm64 architecture is (and will be more) mainstream IMO.
Is this something you considered to support near-future?

build_extra_args not working properly

Hi,
I am trying to change an argument (ARG instruction) in my Docker file but setting build_extra_args: "--build-arg=BRANCH=beta" will be ignored and the argument won't be changed. Build the image locally with the build-arg works fine.

Use 7 chars of GitHub SHA in tag name

I want to tag my images with the first 7 characters of the Git(Hub) SHA.

After looking through the issues here I came across #28 (comment) and came up with this (simplified) GitHub Actions workflow:

jobs:
  my-job:
    runs-on: ubuntu-18.04

    env:
      SHA7: "${GITHUB_SHA:0:7}"

    steps:
    - uses: actions/checkout@v2

    - uses: whoan/docker-build-with-cache-action@v5
      with:
        image_name: my-image
        image_tag: "latest,foo-${SHA7}"
        build_extra_args: --build-arg FOO=Bar
        dockerfile: path/to/Dockerfile
        username: ***
        registry: docker.pkg.github.com
        password: "${{ secrets.GITHUB_TOKEN }}"

This results in this error:

Tagging: foo-${SHA7}
Error parsing reference: "docker.pkg.github.com/<ORGANIZATION>/<REPOSITORY>/my-image:foo-${SHA7}" is not a valid repository/tag: invalid reference format

Feature : option to use build stage name instead of number for the tag of image stages

Hi,

[User story like] :
As a developer
I would like to use intermediate images of multi-stage built during continuous integration using the stage name (e.g : myimage-stages:test instead of myimage-stages:3 if i need to use it later in ci)
So that i can add stages in my dockerfile without breaking ci.

[Gherkin]
Given my dockerfile used named build and I have set "tag_stage_image_by_label = true"
When it run the built of docker-build-with-cache-action
Then staging images should be named like myimage-stages:stage_label

Not sure of the feasibility.

Have a nice day.

Login on the docker.pkg.github.com registry

The documentation on this page suggests it is possible to use docker.pkg.github.com with secrets.DOCKER_USERNAME and secrets.DOCKER_PASSWORD but the documentation does not say how to get those two secrets.

This is contradictory with this page, we should be able to use GITHUB_TOKEN without username/password:

If you are using a GitHub Actions workflow, you can use a GITHUB_TOKEN to publish and consume packages in GitHub Packages without needing to store and manage a personal access token.

Which one is true?

"denied: Resource not accessible by integration"

First of all, it might be user error because I don't quite understand the username part.

I'm trying to use this action like this:

      - uses: whoan/docker-build-with-cache-action@v5
        with:
          dockerfile: docker/images/kuma_base/Dockerfile
          # We'll only want to do this if it's a master build. XXX How do you do that?
          # push_image_and_stages: false
          username: mdn
          password: "${{ secrets.GITHUB_TOKEN }}"
          # XXX Apparently, ghcr.io is the new name. Does that work better?
          registry: docker.pkg.github.com
          # XXX Should this be mdnwebdocs/kuma???
          image_name: kuma

And it works when I use push_image_and_stages: false but that's cheating because that's not actually pushing anything.

We're developers of an organization. The organization is github.com/mdn and I tried putting the username to mdn but I also tried setting it to my personal GitHub username peterbe.

Note that it says "Login Succeeded"...

2020-09-08T12:41:07.4840145Z [Action Step] Checking required input...
2020-09-08T12:41:07.4840337Z 
2020-09-08T12:41:07.4840505Z [Action Step] Log in to registry...
2020-09-08T12:41:07.5558319Z WARNING! Your password will be stored unencrypted in /github/home/.docker/config.json.
2020-09-08T12:41:07.5558652Z Configure a credential helper to remove this warning. See
2020-09-08T12:41:07.5559599Z https://docs.docker.com/engine/reference/commandline/login/#credentials-store
2020-09-08T12:41:07.5559720Z 
2020-09-08T12:41:07.5559884Z Login Succeeded
2020-09-08T12:41:07.5559953Z 
2020-09-08T12:41:07.5560115Z [Action Step] Pulling image...
2020-09-08T12:41:07.7037678Z 
2020-09-08T12:41:07.7038264Z [Action Step] Building image...
2020-09-08T12:41:07.7069974Z + docker build --tag + tee build-output.log
2020-09-08T12:41:07.7070427Z my_awesome_image --file ./docker/images/kuma_base/Dockerfile .
2020-09-08T12:41:08.6841336Z Sending build context to Docker daemon  44.05MB
2020-09-08T12:41:08.6841687Z 
2020-09-08T12:41:08.6913172Z Step 1/23 : FROM python:3.8.0-slim@sha256:7df1fd6bb894e03b488c01fd05eaa4dd677f5b57d800c209f7f0af9867137df9

But it appears to be failing here with: denied: Resource not accessible by integration

2020-09-08T12:49:03.9547247Z Successfully built d0fc99d469df
2020-09-08T12:49:03.9629911Z Successfully tagged my_awesome_image:latest
2020-09-08T12:49:03.9635224Z + set +x
2020-09-08T12:49:03.9635325Z 
2020-09-08T12:49:03.9635937Z [Action Step] Tagging image...
2020-09-08T12:49:03.9636250Z Tag: docker.pkg.github.com/mdn/kuma/kuma:latest
2020-09-08T12:49:03.9922829Z 
2020-09-08T12:49:03.9924019Z [Action Step] Pushing image...
2020-09-08T12:49:03.9924361Z Pushing: latest
2020-09-08T12:49:04.0286124Z The push refers to repository [docker.pkg.github.com/mdn/kuma/kuma]
2020-09-08T12:49:04.0437931Z bf0de1c6f4ae: Preparing
2020-09-08T12:49:04.0438844Z 68edad45c259: Preparing
...snip...
2020-09-08T12:49:04.0448413Z b67d19e65ef6: Waiting
2020-09-08T12:49:04.2831618Z denied: Resource not accessible by integration
2020-09-08T12:49:04.2870564Z 
2020-09-08T12:49:04.2909139Z [Action Step] Log out from registry...
2020-09-08T12:49:04.3102087Z Removing login credentials for docker.pkg.github.com

Hopefully this URL is permanent: https://github.com/mdn/kuma/pull/7456/checks?check_run_id=1085912050

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.