Please make this work with Gitea actions (act runner) and less intrusive when using act runner locally.

[oderwat]

When using setup-beam@v1 in a Gitea action it fails at installing Gleam. Erlang gets installed without problems but after that I get "::error::Unauthorized". To me it is unclear what the problem may be.

::group::Installing Erlang/OTP OTP-27.1.2 - built on amd64/ubuntu-20.04
[command]/usr/bin/tar zx --strip-components=1 --warning=no-unknown-keyword --overwrite -C /tmp/5105a6e4-dad1-4bdb-910c-f155a743e217 -f /tmp/e6949c37-9d91-4cf9-a132-7e88c3a439b1
[command]/tmp/.setup-beam/otp/Install -minimal /tmp/.setup-beam/otp
Installed Erlang/OTP version
[command]/tmp/.setup-beam/otp/bin/erl -version
Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 15.1.2
::endgroup::
::error::Unauthorized

I am currently manually installing everything which works fine. Here my script for reference:

name: test

env:
  OTP_VERSION: "27.2"
  REBAR3_VERSION: "3"
  GLEAM_VERSION: "1.7.0"

on:
  push:
    branches:
      - master
      - main
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Detect architecture
      - name: Set up architecture variables
        run: |
          ARCH=$(uname -m)
          if [ "$ARCH" = "x86_64" ]; then
            echo "ARCH_TAG=amd64" >> $GITHUB_ENV
            echo "GLEAM_ARCH=x86_64-unknown-linux-musl" >> $GITHUB_ENV
          elif [ "$ARCH" = "aarch64" ] || [ "$ARCH" = "arm64" ]; then
            echo "ARCH_TAG=arm64" >> $GITHUB_ENV
            echo "GLEAM_ARCH=aarch64-unknown-linux-musl" >> $GITHUB_ENV
          else
            echo "Unsupported architecture: $ARCH"
            exit 1
          fi          

      # Install Erlang manually
      - name: Install Erlang
        run: |
          cd /tmp
          mkdir -p /tmp/.setup-beam/otp
          curl -O https://builds.hex.pm/builds/otp/${{ env.ARCH_TAG }}/ubuntu-20.04/OTP-${{ env.OTP_VERSION }}.tar.gz
          tar xzf OTP-${{ env.OTP_VERSION }}.tar.gz --strip-components=1 -C /tmp/.setup-beam/otp
          cd /tmp/.setup-beam/otp
          ./Install -minimal /tmp/.setup-beam/otp
          echo "Verifying Erlang installation:"
          /tmp/.setup-beam/otp/bin/erl -version
          # Add to PATH
          echo "/tmp/.setup-beam/otp/bin" >> $GITHUB_PATH          

      # Install rebar3 manually
      - name: Install Rebar3
        run: |
          curl -O https://s3.amazonaws.com/rebar3/rebar3
          chmod +x rebar3
          sudo mv rebar3 /usr/local/bin/
          echo "Verifying Rebar3 installation:"
          rebar3 version          

      # Install Gleam manually
      - name: Install Gleam
        run: |
          curl -L https://github.com/gleam-lang/gleam/releases/download/v${{ env.GLEAM_VERSION }}/gleam-v${{ env.GLEAM_VERSION }}-${{ env.GLEAM_ARCH }}.tar.gz -o gleam.tar.gz
          tar -xf gleam.tar.gz
          chmod +x gleam
          sudo mv gleam /usr/local/bin/
          echo "Verifying Gleam installation:"
          gleam --version          

      # Run your tests
      - run: gleam deps download
      - run: gleam test
      - run: gleam format --check src test

setup-beam@v1 is also working "fine" locally using the same runner as Gitea is using. But it is very unpleasant to follow, because it emit a lot of debug information. Here an example test.log

[starbelly]

We are happy to accept a PR for this support, depending on the level of complexity it might introduce. However, I don't think this is a goal for this project at the moment such that resources can be diverted to implementing said support.

[christoph-heiss]

FWIW, I stumbled across the same problem and this issue.
A quick investigation showed that the ::error::Unauthorized comes from trying to access the GitHub API for retrieving the available Gleam versions in getGleamVersions().
The API needs some sort of authentication token, on GitHub this is directly provided obviously.

For anyone coming across here:

1. Create a PAT - just create a new fine-grained token, w/o any special permissions.
2. Add it to the runner environment globally by e.g. setting

runner:
  envs:
    GITHUB_API_PAT: github_pat_...

or on a per-repo/-user basis on Forgejo under Settings > Actions > Secrets.

3. Pass it to the action

jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: erlef/setup-beam@v1
        with:
          github-token: ${{ env.GITHUB_API_PAT }}

This works at least for Forgejo (Actions).

[oderwat]

@christoph-heiss thanks for this. but to me this is more a work around than a solution. It seems that the action is doing something "special" for getting the Gleam version, while there seems to be no problem for the other repositories. We use a lot of actions with act_runner that do not have this problem. Usually the API token is just needed to prevent rate limiting.

[christoph-heiss]

It seems that the action is doing something "special" for getting the Gleam version, while there seems to be no problem for the other repositories.

Yeah, that definitely weird and what I thought too.
But I'm definitely won't be debugging a proprietary blackbox API. Also, they can change (rate-limit) policies at any time anyway, so using an API token is probably a good idea in any case.

So I definitely rather work around this for the time being - just wanted to share this, in case others stumble upon here.