Instant updates with publish-action

Without doing anything, your new releases reach FlatPark within half a day: FlatPark checks every app’s releases twice a day. If you release on GitHub, the publish-action turns that into minutes: your release workflow tells FlatPark the moment a release goes live, and the update is checked and published right away.

It needs no token and no secret, and there is nothing else to maintain.

Setting it up

Your app has to be listed on FlatPark already, with your GitHub repository as its source. Then add a job to a workflow that runs when you publish a release:

# .github/workflows/release.yml
on:
  release:
    types: [published]

jobs:
  flatpak:
    runs-on: ubuntu-latest
    # A FlatPark hiccup should never fail your release.
    continue-on-error: true
    steps:
      - uses: flatpark/publish-action@v1
        with:
          app-id: com.example.MyApp

Use your app’s id on FlatPark; it is on your app’s page.

If a workflow creates your releases

GitHub doesn’t start new workflow runs for events caused by the default GITHUB_TOKEN. If your release is created by a workflow (tauri-action, softprops/action-gh-release and the like), the on: release workflow above never runs, and nothing reports it. Add the job to the workflow that creates the release instead, after it is published, and pass the tag:

jobs:
  release:
    # … builds and publishes the GitHub release …

  flatpak:
    needs: release
    runs-on: ubuntu-latest
    continue-on-error: true
    steps:
      - uses: flatpark/publish-action@v1
        with:
          app-id: com.example.MyApp
          tag: ${{ github.ref_name }}

The release must be published, not a draft, when the job runs, and its Linux file uploaded. A release whose Linux file arrives later is picked up by the twice-daily check.

What happens after a release

1. The action sends your app id, the tag and your repository name to FlatPark.
2. FlatPark checks that the app is listed, that your repository is its registered source, and that the tag is a published release.
3. It finds the new Linux file, pins its checksum and size, and unpacks it the way an install would.
4. If that works, the update is merged and published without waiting for a person, usually within minutes. flatpak update delivers it to users.

If the new file doesn’t unpack the way the package expects (a renamed binary, a different archive layout), the update stops there. The previous version stays available and FlatPark fixes the package by hand.

Why it needs no secret

Nothing in the request is trusted as sent. FlatPark verifies all of it against public facts: its own catalog, and the release on GitHub. So nobody can use the action to publish a release for a repository they don’t control, and your workflow never holds a FlatPark credential.