Edge Apps GitHub Actions 26.10.2 | Screenly

Edge Apps GitHub Actions 26.10.2: Checks, initialize, and update now come as reusable workflows

Mon, 26 Oct 2026 00:00:00 +0000

Until this release, every Edge App repo carried its own full copy of the example workflows: the triggers, the jobs for each environment, the production tag check, and the id expressions. Now those live in this repo as reusable workflows, and an app’s workflow file calls them:

name: Update Edge App

on:
 workflow_dispatch:
 push:
 branches: [main, master]
 tags: ['v[0-9]*']

permissions:
 contents: read

jobs:
 update:
 uses: Screenly/edge-apps-actions/.github/workflows/update.yml@v26.10.2
 secrets:
 SCREENLY_API_TOKEN: ${{ secrets.SCREENLY_API_TOKEN }}

When a later release changes how deploys work, bumping that pin is all it takes. Copy the 3 files in examples/ into your app’s .github/workflows/ to start.

Workflow	Inputs	Secrets
`checks.yml`	`bun-version` (default `latest`)	none
`initialize.yml`	`environment`, `edge_app_name`, `edge_app_title`	`SCREENLY_API_TOKEN`
`update.yml`	`delete_missing_settings` (default `true`)	`SCREENLY_API_TOKEN`

update.yml deploys to stage on a push or a manual run on the default branch, and other branches never deploy. It deploys to production when you push a v* tag whose commit is on the default branch, through the production environment and its reviewers. checks.yml cancels a check still running on a branch when a newer push to that branch arrives.

Setting up an app

Create the GitHub environments stage and production, and add SCREENLY_API_TOKEN to each as an environment secret. An environment secret only reaches jobs that run in that environment, so the production token stays behind production’s reviewers.
Run “Initialize Edge App” for stage. Once the run has finished successfully, set the repository variable STAGE_EDGE_APP_ID to the id in its job summary. Setting it earlier lets a deploy start while Initialize is still running.
Do the same for production and PRODUCTION_EDGE_APP_ID.

delete_missing_settings is true in update.yml, so the manifest decides which settings exist. The update action on its own still defaults to false. To keep settings that aren’t in your manifest, pass delete_missing_settings: false under with:.

The checks, initialize, and update actions are still there to use as steps in a workflow of your own.

Edge Apps GitHub Actions 26.10.2: Deploys to an environment run one at a time

Mon, 26 Oct 2026 00:00:00 +0000

Merge 3 pull requests into main in a row, and the update workflow deploys the first to stage while the second waits. When the third arrives, it takes the second’s place in line. Stage ends up on the newest commit after 2 deploys, and a running deploy is never cancelled to get there.

Production tags queue the same way, separately from stage. If an older production run is still waiting for a reviewer, reject it so the newest one goes next.

Initialize has a queue of its own, so a push can’t take the place of an Initialize run that’s waiting.

To redo a failed or cancelled production deploy, re-run that tag’s workflow run. You don’t need a new tag. If the earlier run stopped part-way, the re-run can report success while the app stays on its previous revision, so check the live revision in Screenly afterward. If it didn’t move, push a new tag with a change to the app’s files.

Edge Apps GitHub Actions 26.10.2: The initialize action won't create the same app twice, and other fixes

Mon, 26 Oct 2026 00:00:00 +0000

Fixes

If package.json can’t be parsed, initialize and update stop with an error instead of deploying the repo root.

Improvements

initialize stops if an Edge App with the same name already exists in that environment, so running it twice can’t create 2 apps. If it can’t get the list of Edge Apps to check, it stops without creating anything.