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

Cleanup aliases created by this action in post-step of action #125

Open
hashhar opened this issue Feb 18, 2022 · 4 comments · May be fixed by #139
Open

Cleanup aliases created by this action in post-step of action #125

hashhar opened this issue Feb 18, 2022 · 4 comments · May be fixed by #139

Comments

@hashhar
Copy link

hashhar commented Feb 18, 2022

Behaviour

Steps to reproduce this issue

  1. Add a step to workflow which uses this action and run it on a self-hosted runner.
  2. Once workflow finishes login to the hosted runner and notice that docker build is using buildx instead of traditional builder.

Expected behaviour

This action should run docker buildx uninstall in the post-step of the action to ensure any future runs on same machine use the traditional builder when invoked via docker build unless configured otherwise.

Actual behaviour

The alias installed by this action isn't removed and hence all future calls to docker build end up going through buildx instead of traditional builder.

Logs

This applies across runs so logs of run don't make sense. However it manifest like:

...
2022-02-18T16:29:22.0891103Z Download action repository 'AutoModality/[email protected]' (SHA:d004b47eb728f2a83316fc70ba9a62ef97278013)
2022-02-18T16:29:22.4238003Z Download action repository 'actions/checkout@v2' (SHA:ec3a7ce113134d7a93b817d10a8272cb61118579)
2022-02-18T16:29:22.8949727Z ##[group]Build container for action use: '/home/concord/actions-runner-x86_64/_work/_actions/AutoModality/action-clean/1.1.0/Dockerfile'.
2022-02-18T16:29:22.8994603Z ##[command]/usr/bin/docker build -t fee7dc:3ef02aa84a984bee8d616813f987552e -f "/home/concord/actions-runner-x86_64/_work/_actions/AutoModality/action-clean/1.1.0/Dockerfile" "/home/concord/actions-runner-x86_64/_work/_actions/AutoModality/action-clean/1.1.0"
2022-02-18T16:29:23.0282761Z time="2022-02-18T16:29:23Z" level=warning msg="No output specified for docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load"
2022-02-18T16:29:23.2871580Z #1 [internal] load build definition from Dockerfile
2022-02-18T16:29:23.2874612Z #1 transferring dockerfile: 289B 0.0s done
2022-02-18T16:29:23.2875276Z #1 DONE 0.0s
2022-02-18T16:29:23.2875493Z 
2022-02-18T16:29:23.2875820Z #2 [internal] load .dockerignore
2022-02-18T16:29:23.2876638Z #2 transferring context: 2B done
2022-02-18T16:29:23.2877096Z #2 DONE 0.0s
2022-02-18T16:29:23.4345965Z 
2022-02-18T16:29:23.4347150Z #3 [internal] load metadata for docker.io/library/ubuntu:latest
2022-02-18T16:29:23.5377896Z #3 DONE 0.2s
2022-02-18T16:29:23.5378757Z 
2022-02-18T16:29:23.5379505Z #4 [1/2] FROM docker.io/library/ubuntu@sha256:669e010b58baf5beb2836b253c1fd5768333f0d1dbcb834f7c07a4dc93f474be
2022-02-18T16:29:23.5380428Z #4 resolve docker.io/library/ubuntu@sha256:669e010b58baf5beb2836b253c1fd5768333f0d1dbcb834f7c07a4dc93f474be done
2022-02-18T16:29:23.5381216Z #4 DONE 0.0s
2022-02-18T16:29:23.5381489Z 
2022-02-18T16:29:23.5381772Z #5 [internal] load build context
2022-02-18T16:29:23.5382298Z #5 transferring context: 35B done
2022-02-18T16:29:23.5427540Z #5 DONE 0.0s
2022-02-18T16:29:23.5429640Z 
2022-02-18T16:29:23.5430420Z #6 [2/2] COPY entrypoint.sh /entrypoint.sh
2022-02-18T16:29:23.5431275Z #6 CACHED
2022-02-18T16:29:23.5564127Z ##[endgroup]
...
2022-02-18T16:29:23.6926980Z ##[command]/usr/bin/docker run --name fee7dc3ef02aa84a984bee8d616813f987552e_0dcb11 --label fee7dc --workdir /github/workspace --rm -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_RUN_ATTEMPT -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_REF_NAME -e GITHUB_REF_PROTECTED -e GITHUB_REF_TYPE -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e RUNNER_OS -e RUNNER_ARCH -e RUNNER_NAME -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/concord/actions-runner-x86_64/_work/_temp/_github_home":"/github/home" -v "/home/concord/actions-runner-x86_64/_work/_temp/_github_workflow":"/github/workflow" -v "/home/concord/actions-runner-x86_64/_work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/concord/actions-runner-x86_64/_work/starburst-release-flows/starburst-release-flows":"/github/workspace" fee7dc:3ef02aa84a984bee8d616813f987552e
2022-02-18T16:29:23.7289825Z Unable to find image 'fee7dc:3ef02aa84a984bee8d616813f987552e' locally
2022-02-18T16:29:23.9644592Z docker: Error response from daemon: pull access denied for fee7dc, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
2022-02-18T16:29:23.9654644Z See 'docker run --help'.
2022-02-18T16:29:23.0282761Z time="2022-02-18T16:29:23Z" level=warning msg="No output specified for docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load"
2022-02-18T16:29:23.2871580Z #1 [internal] load build definition from Dockerfile
2022-02-18T16:29:23.2874612Z #1 transferring dockerfile: 289B 0.0s done
2022-02-18T16:29:23.2875276Z #1 DONE 0.0s

This output suggests that buildx got used even when the command was /usr/bin/docker build -t fee7dc:3ef02aa84a984bee8d616813f987552e -f "/home/concord/actions-runner-x86_64/_work/_actions/AutoModality/action-clean/1.1.0/Dockerfile" "/home/concord/actions-runner-x86_64/_work/_actions/AutoModality/action-clean/1.1.0"

@hashhar
Copy link
Author

hashhar commented Feb 18, 2022

The fix should go here

async function cleanup(): Promise<void> {

It should be running docker buildx uninstall to remove alias (if configured).

@crazy-max
Copy link
Member

@hashhar Can you post your workflow?

@hashhar
Copy link
Author

hashhar commented Feb 18, 2022

Not the exact workflow but a minimal reproduction I was able to verify with.

If you run:

name: Build multi-platform image

on:
  workflow_dispatch:

jobs:
  buildx:
    runs-on: [self-hosted, very-specific-label-to-match-just-one-machine]
    steps:
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v1
      - uses: docker/setup-buildx-action@v1
        id: buildx
        with:
          install: true    # NOTICE THE install: true which installs the alias (but doesn't remove it)
      - name: Inspect builder
        run: |
          echo "Name:      ${{ steps.buildx.outputs.name }}"
          echo "Endpoint:  ${{ steps.buildx.outputs.endpoint }}"
          echo "Status:    ${{ steps.buildx.outputs.status }}"
          echo "Flags:     ${{ steps.buildx.outputs.flags }}"
          echo "Platforms: ${{ steps.buildx.outputs.platforms }}"

Then run the next one on same hosted runner:

name: "release"

on:
  workflow_dispatch:

jobs:
  get-starburst-enterprise-repo-sha:
    runs-on: [ self-hosted, very-specific-label-to-match-just-one-machine ]
    name: Get repo SHA
    steps:
      - name: Dump environment
        uses: hmarr/[email protected]
      - name: Cleanup node
        uses: AutoModality/[email protected]

You'll get into situation as described above.

Note that self-hosted runners aren't ephemeral necessarily so any changes you make to the machine itself will persist and observed by future workflows.

To confirm you can add a step like:

- name: Inspect docker client config
   run: cat ~/.docker/*

It'll show that an alias has been added to execute buildx when build is used (as described in your docs for the install: true input to the action.

@crazy-max
Copy link
Member

crazy-max commented Mar 3, 2023

This action should run docker buildx uninstall in the post-step of the action to ensure any future runs on same machine use the traditional builder when invoked via docker build unless configured otherwise.

I think removing the alias in a post step would not solve your issue but makes it worst. Using install on a self-hosted runner is racy. If you trigger multiple runs on the same runner then docker buildx uninstall could run in the middle of another workflow. I think in your case you should set first an unique Docker config path for each run and cleanup afterwards like:

jobs:
  buildx:
    runs-on: [self-hosted, very-specific-label-to-match-just-one-machine]
    steps:
      -
        name: Set Docker config
        run: |
          dockerConfig=${HOME}/.docker-${{ env.GITHUB_RUN_ID }}
          mkdir -p "${dockerConfig}"
          echo "DOCKER_CONFIG=${dockerConfig}" >> $GITHUB_ENV
      -
        name: Set up Buildx
        uses: docker/setup-buildx-action@v2
        with:
          install: true
      # ... more steps to build, etc...
      -
        # last step for this job
        name: Cleanup Docker config
        if: always()
        run: |
          rm -rf ${DOCKER_CONFIG}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants