build-push-action VS upload-artifact

Starting with version 4, docker/build-push-action builds images using the OCI format by default. OCI (Open Container Initiative) is the modern standard that is supported by AWS ECR. However, AWS Lambda does not support OCI image manifests. Lambda only accepts the older Docker v2 schema: application/vnd.docker.distribution.manifest.v2+json

docker/build-push-action

Does build-push-action solve this? I haven’t used their multi-arch configs but I was under the impression that it was pretty smooth.

https://github.com/docker/build-push-action

To publish images to Docker Hub, I use the docker/build-push-action@v6, where I specify:

Docker Build and Publish:

## Local Cache This method leverages local storage for caching Docker layers. The downside is that old cache entries aren’t deleted automatically, so the cache size might increase over time. A temporary fix involves moving and cleaning the cache after each build. ```yaml //".github/workflows/build.yml" name: Docker Build on: push: jobs: docker: runs-on: ubuntu-latest steps: - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 // highlight-start - name: Cache Docker layers uses: actions/cache@v4 with: path: /tmp/.buildx-cache key: ${{ runner.os }}-buildx-${{ github.sha }} restore-keys: | ${{ runner.os }}-buildx- // highlight-end - name: Login to Docker Hub uses: docker/login-action@v3 with: username: ${{ vars.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} // highlight-start - name: Build and push uses: docker/build-push-action@v6 with: push: true tags: user/app:latest cache-from: type=local,src=/tmp/.buildx-cache cache-to: type=local,dest=/tmp/.buildx-cache-new,mode=max // highlight-end - # Temp fix # https://github.com/docker/build-push-action/issues/252 # https://github.com/moby/buildkit/issues/1896 name: Move cache run: | rm -rf /tmp/.buildx-cache mv /tmp/.buildx-cache-new /tmp/.buildx-cache

Configuring the GitHub Actions Workflow We set up a GitHub Actions workflow to automate the integration and deployment process. The integration workflow is triggered on every pull request while the deployment workflow was triggered upon the completion of the build and push workflow for docker images gotten from the marketplace. It used the appleboy/ssh-action to execute the deployment script on the server.

We use the docker/build-push-action to build the application image. In addition to setting the correct tag, the image build step must also provide a label matching your service name. Because the image should be pushed to your container registry, we set push: true, and because we want ludicrous build speed we instruct the build step to utilize the GitHub Actions cache.

name: Lint and Dockerize the app on: push: branches: [master] pull_request: branches: [master] env: # Use docker.io for Docker Hub if empty REGISTRY: docker.io # github.repository as / IMAGE_NAME: ${{ github.repository }} jobs: build: runs-on: ubuntu-latest permissions: contents: read packages: write steps: - name: Checkout repository uses: actions/checkout@v2 - name: Set up Google Cloud uses: google-github-actions/[email protected] with: project_id: ${{ secrets.GCP_PROJECT_ID }} service_account_key: ${{ secrets.GCP_SA_KEY }} # Login against a Docker registry except on PR # https://github.com/docker/login-action - name: Log into registry ${{ env.REGISTRY }} # if: github.event_name != 'pull_request' uses: docker/login-action@v1 with: username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_PASSWORD }} # Extract metadata (tags, labels) for Docker # https://github.com/docker/metadata-action #- name: Extract Docker metadata # id: meta # uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38 # with: # images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} # Build and push Docker image with Buildx (don't push on PR) # https://github.com/docker/build-push-action - name: Build and push Docker image uses: docker/build-push-action@v2 with: context: ./ tags: ${{ secrets.DOCKER_USERNAME }}/magga:latest push: true file: ./Dockerfile - name: Image digest run: echo

I have a small gripe that I think exemplifies a bigger problem. actions/upload-artifact strips executable permissions from binaries (1). The fact they fucked this up in the first place, and six years later haven't fixed it, gives me zero confidence in the team managing their platform. And when I'm picking a CI/CD service, I want reliability and correctness. GH has neither.

When it takes all of a day to self host your own task runner on a laptop in your office and have better uptime, lower cost, better performance, and more correct implementations, you have to ask why anyone chooses GHA. I guess the hello-world is convincing enough for some people.

(1) https://github.com/actions/upload-artifact/issues/38

Github's response was pretty bad. They changed the upload-artifacts workflow to no longer include hidden files _in a minor release_ and that broke thousands of workflows that required hidden files.

Github issue with angry comments: https://github.com/actions/upload-artifact/issues/602

upload-artifact

Here, the concept of "upload" is a little confusing. What the GitHub action upload-artifact does is to "copy" the jar file to a publicly accessible folder.

The content of the build destination folder folder needs is saved and transferred to the following jobs in the workflow. We do this with the Github actions actions/upload-artifact

The action for uploading the artifact doesn't do too much, but it takes care of all the nuance around GitHub Pages artifacts specifically. You can view the action's source here. It will tar the path (provided by the with option) and then call the upload artifact action. The artifact's name is github-pages and has a 1 day expiration. This artifact has the name and format required for the deploy action. It all just works (so far).