`curl: command not found` when job runs in container

[mcuelenaere]

Uploading the test results fails with curl: command not found. Unsure why such a basic utility would be missing. This was our first experience setting up Buildpulse.

Full logs:

Run Workshop64/buildpulse-action@main
  with:
    account: ***
    repository: ***
    path: ./test-results.xml
    key: ***
    secret: ***
    repository-path: .
  env:
    NPM_CONFIG_USERCONFIG: /__w/_temp/.npmrc
    NODE_AUTH_TOKEN: ***
Run $GITHUB_ACTION_PATH/run.sh
  $GITHUB_ACTION_PATH/run.sh
  shell: bash --noprofile --norc -e -o pipefail {0}
  env:
    NPM_CONFIG_USERCONFIG: /__w/_temp/.npmrc
    NODE_AUTH_TOKEN: ***
    INPUT_ACCOUNT: ***
    INPUT_REPOSITORY: ***
    INPUT_PATH: ./test-results.xml
    INPUT_KEY: ***
    INPUT_SECRET: ***
    INPUT_CLI_URL: 
    INPUT_REPOSITORY_PATH: .
+ curl -fsSL --retry 3 --retry-connrefused --connect-timeout 5 https://get.buildpulse.io/test-reporter-linux-amd64
/__w/_actions/Workshop64/buildpulse-action/main/run.sh: line 73: curl: command not found
+ curl -fsSL --retry 3 --retry-connrefused --connect-timeout 5 https://github.com/buildpulse/test-reporter/releases/latest/download/test-reporter-linux-amd64
/__w/_actions/Workshop64/buildpulse-action/main/run.sh: line 73: curl: command not found
Warning: Unable to send test results to BuildPulse. See details below.

Downloading the BuildPulse test-reporter failed with status 127.

We never want BuildPulse to make your builds unstable. Since we're having
trouble downloading the BuildPulse test-reporter, we're skipping the
BuildPulse analysis for this build.

If you continue seeing this problem, please get in touch at
https://buildpulse.io/contact so we can look into this issue.

Job environment:

Current runner version: '2.288.1'
Operating System
  Ubuntu
  20.04.4
  LTS
Virtual Environment
  Environment: ubuntu-20.04
  Version: 20220227.1
  Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20220227.1/images/linux/Ubuntu2004-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20220227.1
Virtual Environment Provisioner
  1.0.0.0-main-20220307-1
GITHUB_TOKEN Permissions
  Actions: write
  Checks: write
  Contents: write
  Deployments: write
  Discussions: write
  Issues: write
  Metadata: read
  Packages: write
  Pages: write
  PullRequests: write
  RepositoryProjects: write
  SecurityEvents: write
  Statuses: write
Secret source: Actions
Prepare workflow directory
Prepare all required actions
Getting action download info
Download action repository 'actions/checkout@v3' (SHA:a12a3943b4bdde767164f792f33f40b04645d846)
Download action repository 'actions/setup-node@v3' (SHA:9ced9a43a244f3ac94f13bfd896db8c8f30da67a)
Download action repository 'actions/cache@v3' (SHA:4b0cf6cc4619e737324ddfcec08fff2413359514)
Download action repository 'Workshop64/buildpulse-action@main' (SHA:d0055c20c53dfefe15d2caa5bd5430da576f440f)

Relevant excerpt from workflow:

    runs-on: ubuntu-latest
    container:
      image: ubuntu:latest

[jasonrudolph]

👋 @mcuelenaere: Thanks for reporting this!

This is really bizarre, and it's definitely not the experience I want people to have. 😬

I haven't been able to reproduce this just yet, but I'm looking into it today.

Thanks for including the job environment info:

Virtual Environment
Environment: ubuntu-20.04
Version: 20220227.1
Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20220227.1/images/linux/Ubuntu2004-Readme.md

I've never had any issues with curl being unavailable in a GitHub Actions Ubuntu environment in the past, but I confirmed that it should indeed be present according to the docs.

I'll investigate this further, and I'll follow up with you today.

[mcuelenaere]

This error is indeed very puzzling, I haven't rerun the workflow yet (doing that now). Maybe this was just a fluke?
EDIT: rerunning the workflow reproduces the issue

This is the complete workflow job (certain parts have been censored):

test:
    name: Test
    runs-on: ubuntu-latest
    container:
      image: ubuntu:latest
    services:
      redis:
        image: redis:6
        ports:
          - 6379/tcp
      mysql:
        image: mysql:5.7
        ports:
          - 3306/tcp
        env:
          MYSQL_ROOT_PASSWORD: ***
          MYSQL_DATABASE: ***
      vault:
        image: vault:1.5.0
        ports:
          - 8200/tcp
        env:
          VAULT_DEV_ROOT_TOKEN_ID: ***
        options: "--cap-add IPC_LOCK"
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '16'
          scope: ***
          registry-url: 'https://npm.pkg.github.com/'
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
      - name: Cache NPM
        uses: actions/cache@v3
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-
      - name: Install dependencies
        run: npm i
      - name: Linting
        run: npm run lint
      - name: Validate TypeScript
        run: npm run check:typescript
      - name: Tests
        run: npm run test:ci
        env:
          NODE_ENV: ci
          TS_NODE_TRANSPILE_ONLY: "true"
          TZ: UTC
      - name: Upload test results to BuildPulse for flaky test detection
        if: '!cancelled()'
        uses: Workshop64/buildpulse-action@main
        with:
          account: ***
          repository: ***
          path: ./test-results.xml
          key: ${{ secrets.BUILDPULSE_ACCESS_KEY_ID }}
          secret: ${{ secrets.BUILDPULSE_SECRET_ACCESS_KEY }}

[jasonrudolph]

This is the complete workflow job (certain parts have been censored):

Thanks so much for that, @mcuelenaere. After seeing the workflow definition, I was able to reproduce the issue.

For some reason, this entry in the workflow job triggers the problem:

    container:
      image: ubuntu:latest

I pushed up an example repository in a branch to reproduce the issue.

Without the container entry in the workflow, we can see the BuildPulse action complete successfully:

https://github.com/Workshop64/buildpulse-action/runs/5719824952?check_suite_focus=true#step:6:43

Then, I added the container entry in fa34615, and it reproduces the problem:

https://github.com/Workshop64/buildpulse-action/runs/5719839279?check_suite_focus=true#step:7:23

I don't yet know why the container entry causes this problem, but I'm going to look into that next. I'll let you know what I find out.

Thanks again for sharing the workflow definition to help reproduce this problem!

[jasonrudolph]

@mcuelenaere: I suspect I'll need to open an issue in the @actions org to try to figure out why we're seeing this problem. To unblock you in the meantime, I found a solution that you could use temporarily while I investigate this further:

This patch resolves the problem: fa34615...efc1ff1

To do so, it does two things:

1. Uses an older version of the action from when it was a Docker-based action instead of a composite action.
2. Installs the latest version of Git so that the job clones the Git repo instead of downloading a tarball of the repository contents. (Prior to this change, we can see that the job downloads a tarball here, which means that there is no Git repository available to the BuildPulse action here.)

With those two changes in place, the BuildPulse action completes successfully even with the container entry in the workflow: https://github.com/Workshop64/buildpulse-action/runs/5721301698?check_suite_focus=true#step:9:29

Is this something that you'd be willing to try?

[mcuelenaere]

@jasonrudolph that seems to work, yes!

[jasonrudolph]

that seems to work, yes!

@mcuelenaere: Great! I'm glad that got things working for you.

I'm sorry for the clunky workaround. Thanks for your flexibility.

I've asked about this problem in community/community#13718. Hopefully we'll hear back from the @actions team or the community to find out if this is a bug with composite actions or if there's a different approach that I need to use in this action.