GitHub Action reference

The minimum step

- name: Publish to BetaDrop
  id: betadrop
  uses: betadrop-app/upload-action@v1
  with:
    file: app/build/outputs/apk/release/*.apk
    token: ${{ secrets.BETADROP_TOKEN }}

Two required inputs and nothing else. Create the token under Settings → Developer → API tokens in the BetaDrop dashboard, then store it as a repository or organisation secret. Never inline in the workflow file, where it is readable by anyone who can read the repo and is captured in every fork.

Pin the tag. @v1 tracks backwards-compatible releases of the major version; pin a full version such as @v1.2.0 to freeze it entirely. A branch reference is not a supported way to consume this Action.

Inputs

That is the complete list. There is no input for platform or visibility: platform is inferred from the file. Expiry can be set here, with the three limits above, or changed on the build in the dashboard afterwards.

Outputs

A link nobody sees is a wasted upload. The Action already writes it to the run summary on every green build, and comment-on-pr puts it on the pull request without a second step. Use the output when you want it somewhere else — chat, a release note, a downstream job. The integrations guide has those as copy-ready steps.

A complete job

name: Beta
on:
  push:
    branches: [main]

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

      # …your existing build steps produce the .apk or .ipa here…

      - name: Publish to BetaDrop
        id: betadrop
        uses: betadrop-app/upload-action@v1
        with:
          file: app/build/outputs/apk/release/*.apk
          token: ${{ secrets.BETADROP_TOKEN }}
          name: MyApp ${{ github.ref_name }}
          notes: ${{ github.event.head_commit.message }}

      - name: Publish the link to the run summary
        run: echo "${{ steps.betadrop.outputs.install-url }}" >> "$GITHUB_STEP_SUMMARY"

The build steps are deliberately elided: whatever already produces your .apk or .ipa stays exactly as it is, and this Action is appended to it. If you do not have those steps yet, the guide carries full Gradle and Xcode jobs, including the export-options detail that trips up iOS runs.

When it fails

Notes on how it behaves

• Node is assumed, not installed. Every GitHub-hosted runner image ships Node, so the Action needs no setup step. On a self-hosted runner without Node 18 or newer, add one — the Action installs the CLI with npm install -g.
• Inputs are passed through the environment. They are not interpolated into the shell script, so a filename or a commit message containing shell metacharacters cannot inject a command. This is the standard composite-action footgun and it is worth knowing it has been avoided.
• Permissions, only if you comment. Publishing needs no permissions block at all — the upload authenticates with your BetaDrop token and never touches GITHUB_TOKEN. Setting comment-on-pr is the one exception: that step writes to the pull request, so the job needs pull-requests: write. If it is missing the step warns and the run stays green, because a published build should not be lost to a permission.
• It is the CLI. Anything documented on the CLI page about extensions, the ZIP magic-byte check, size limits or error behaviour applies here unchanged, because it is literally the same program running.
• The repository. Source and releases live at github.com/betadrop-app/upload-action. Note the namespace: betadrop-app, not betadrop, which is an unrelated account. Issues and pull requests are read there; a star is how the next team looking for this finds it rather than writing the step themselves.