Issues running in Enterprise GitHub

[lnhrdt]

Our team has been using this action successfully in Public GitHub (github.com), but after migrating to a self-hosted Enterprise GitHub instance have not been able to use this action.

Whenever we use the action in our workflow:

jobs:
  some-job:

    runs-on: highcpu # our self-hosted runner

    # ...

    - uses: carvel-dev/setup-action@v2
      with:
        token: ${{ github.token }}

we get the following error (with debug logging enabled):

##[debug]Evaluating condition for step: 'Run carvel-dev/setup-action@v2'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Run carvel-dev/setup-action@v2
##[debug]Loading inputs
##[debug]Evaluating: github.token
##[debug]Evaluating Index:
##[debug]..Evaluating github:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'token'
##[debug]=> '***'
##[debug]Result: '***'
##[debug]Loading env
Run carvel-dev/setup-action@v2
/usr/bin/docker exec  35b0b5831c39ec77c3ffe09942531b4aad231ce384d808328e3609b8a78d116c sh -c "cat /etc/*release | grep ^ID"
##[debug]ID=ubuntu
##[debug]ID_LIKE=debian
##[debug]Running JavaScript Action with default external tool: node20
Installing ytt:latest, kbld:latest, kapp:latest, kwt:latest, imgpkg:latest, vendir:latest, kctrl:latest
Error: Not Found
##[debug]Node Action run completed with exit code 1
##[debug]Finishing: Run carvel-dev/setup-action@v2

The Error: Not Found log doesn't give us much to go on.

Just to rule out some troubleshooting possibilities, other popular "setup actions" work fine in our environment including:

• actions/setup-java@v4
• gradle/actions/setup-gradle@v4
• docker/setup-buildx-action@v3
• buildpacks/github-actions/setup-pack@v5.8.3

And our current workaround of creating our own action also works fine:

# .github/actions/setup-carvel/action.yml
name: Setup Carvel apps

runs:
  using: composite
  steps:
    - name: Setup imgpkg
      shell: bash
      run: |
        set -euo pipefail
        REPO=carvel-dev/imgpkg
        VERSION=$(curl -s https://api.github.com/repos/$REPO/releases/latest | jq -r .tag_name)
        echo "Installing $REPO $VERSION"

        OS=$(uname | tr '[:upper:]' '[:lower:]')
        ARCH=$(uname -m)
        if [ "$ARCH" = "x86_64" ]; then ARCH=amd64; elif [ "$ARCH" = "aarch64" ]; then ARCH=arm64; fi

        URL="https://github.com/$REPO/releases/download/$VERSION/imgpkg-${OS}-${ARCH}"
        echo "Downloading from $URL"
        curl -sSL -o imgpkg "$URL"

        chmod +x imgpkg
        mv imgpkg /usr/local/bin/

        echo
        imgpkg version

    - name: Setup kbld
      shell: bash
      run: |
        set -euo pipefail
        REPO=carvel-dev/kbld
        VERSION=$(curl -s https://api.github.com/repos/$REPO/releases/latest | jq -r .tag_name)
        echo "Installing $REPO $VERSION"

        OS=$(uname | tr '[:upper:]' '[:lower:]')
        ARCH=$(uname -m)
        if [ "$ARCH" = "x86_64" ]; then ARCH=amd64; elif [ "$ARCH" = "aarch64" ]; then ARCH=arm64; fi

        URL="https://github.com/$REPO/releases/download/$VERSION/kbld-${OS}-${ARCH}"
        echo "Downloading from $URL"
        curl -sSL -o kbld "$URL"

        chmod +x kbld
        mv kbld /usr/local/bin/

        echo
        kbld version

so we feel confident there's no networking issues from our Enterprise GitHub to the resources this action needs to download.

Any ideas?

[Zerpet]

I had the same issue in our company. Back when I look at this (around 2023), the root cause was how this library initialises the github toolkit library.

By default, the toolkit configures the GitHub server URL to wherever is running. In case of GitHub, the github URL will be github.com, and for GHE, it will be your-company-github.example.com. The action then naively tries to download from <server-url>/carvel-dev/<project>. Logically, carvel repos do not exist in your GHE instance, therefore you get this unhelpful "Not Found".

I didn't find a different workaround than yours back in the day. To add support for GHE, this Action requires code changes. But given how little attention this repo is getting (look at piled PRs), I think that's unlikely 😔

[lnhrdt]

Thanks for the insight @Zerpet! Hopefully someone can help eventually.