feat: automated upstream release watcher for pritunl-zero

[Copilot]

Adds a polling workflow that watches pritunl/pritunl-zero for new GitHub Releases and automatically dispatches the build+push pipeline when one is detected.

New: .github/workflows/watch-pritunl-zero-release.yml

• Runs hourly (cron) and supports manual workflow_dispatch
• Fetches latest release tag via gh api, strips leading v to produce version
• Compares against persisted tag in .github/upstream-versions/pritunl-zero.txt; exits early if unchanged
• On new release: dispatches docker-image.yml with version + upstream_tag inputs, then commits/pushes updated state file
• Commit step guarded by success() — a failed dispatch won't silently advance the stored tag
• contents: write + actions: write permissions; concurrency group prevents overlapping runs

Updated: .github/workflows/docker-image.yml

• Added optional upstream_tag input (raw tag, e.g. v1.2.3)
• Added echo step at job start to surface received inputs for easy validation
• All existing triggers and build steps unchanged

New: .github/upstream-versions/pritunl-zero.txt

Empty state file; first watcher run will always fire a dispatch. To force a re-dispatch on a later run, reset this file to an older/blank value.

Manual test

1. Go to Actions → Watch pritunl-zero releases and dispatch build → Run workflow
2. Confirm the dispatched docker-image.yml run shows correct version/upstream_tag in the echo step
3. To re-trigger: clear or downgrade .github/upstream-versions/pritunl-zero.txt and re-run the watcher

Original prompt

Create a pull request in repository yarons/pritunl-zero-docker that adds an automated “upstream release watcher” GitHub Actions workflow.

Context / goal

• User wants to trigger their existing build+push pipeline via workflow_dispatch whenever a new GitHub Release is published in https://github.com/pritunl/pritunl-zero.
• User does NOT control the upstream repo, so polling is required.

Watcher behavior

• Add a watcher workflow under .github/workflows/ (name appropriately) that:
  1. Runs on a schedule (hourly is fine) and also supports manual workflow_dispatch.
  2. Queries the upstream repo’s latest release via GitHub API.
  3. Reads and compares a persisted “last seen” tag stored in .github/upstream-versions/pritunl-zero.txt.
  4. If unchanged, exits without dispatching.
  5. If changed:
     • Computes version by stripping a single leading v from the upstream tag (e.g. v1.2.3 -> 1.2.3).
     • Triggers the existing build workflow using workflow_dispatch, passing inputs (version + upstream_tag).
     • Updates .github/upstream-versions/pritunl-zero.txt to the new upstream tag and commits/pushes that change back to the default branch.

Build workflow updates

• Detect the existing build+push workflow file (under .github/workflows/).
• Ensure it supports workflow_dispatch with inputs:
  • version (no leading v)
  • upstream_tag (raw tag, e.g. v1.2.3)
• Do not break existing triggers (keep existing on: triggers intact).
• Add a small step that echoes the received inputs so it’s easy to validate.

Permissions and safety

• Watcher workflow should set permissions:
  • contents: write (commit state file)
  • actions: write (dispatch workflow)
• Add concurrency to prevent overlapping watcher runs.
• Use GITHUB_TOKEN (default token) and gh CLI for API calls and to dispatch the build workflow.
• Do not hardcode branch names; push back to the checked-out default branch.

Testing / validation

• Add a lightweight validation step in watcher that prints the fetched tag and computed version.
• In the PR description, include instructions to test manually:
  • run watcher via workflow_dispatch
  • optionally edit .github/upstream-versions/pritunl-zero.txt to an older value to force a dispatch.

Keep changes minimal and focused.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Can I trigger GitHub action on my repo when another repo has released a new version?

Assistant: Yes—there are a few common ways to do this, depending on who “owns” the other repo and what kind of release signal you can rely on.

Option 1 (best when you control both repos): repository_dispatch

Flow

1. In the other repo, run a workflow on release (or when a release is published).
2. That workflow calls the GitHub API to send a repository_dispatch event to your repo.
3. In your repo, a workflow with on: repository_dispatch runs.

Pros: near real-time, reliable, no polling.
Cons: needs a token with permission to dispatch to your repo.

Option 2 (often simplest): scheduled polling in your repo

Flow

1. In your repo, run a scheduled workflow (on: schedule) every X minutes/hours.
2. The job checks the other repo’s “latest release” via the GitHub API.
3. If it changed since last run, proceed; otherwise exit.

Pros: works even if you don’t control the other repo.
Cons: not instant; you need to store “last seen” release tag/version somewhere (artifact, cache, issue/commit, GitHub environment variable, etc.).

Option 3 (public repo releases): subscribe via webhooks → dispatch

GitHub webhooks can notify on release, but they deliver to an HTTP endpoint you host. That endpoint can then trigger your repo (again via repository_dispatch or workflow_dispatch).

Pros: real-time and works when you don’t control the other repo (if you can configure webhook).
Cons: requires running/hosting a small service; and you must be able to configure a webhook on the other repo.

Option 4: reusable workflow (workflow_call) doesn’t “listen” to releases

Reusable workflows are great for sharing CI logic, but they don’t automatically trigger from another repo’s release unless something (a workflow) calls them. So they’re not a standalone solution to “on external release”.

---

Quick question so I can point you to the right setup

Do you control the other repo (i.e., can you add a workflow/webhook to it), or is it a third-party repo you can only read from? Also, is the other repo public or private?

User: No, I don't.

Assistant: If you don’t control the other repo, then your realistic options are:

1) Poll for new releases on a schedule (most common)

In your repo, run a scheduled workflow that checks the other repo’s latest release/tag via the GitHub API, and only continues when it changes.

Trigger:

• on: schedule (plus optionally workflow_dispatch so you can test manually)

**Che...

This pull request was created from Copilot chat.