Add updater workflow

[Hazmi35]

This PR adds an automatic workflow to keep CLOUDFLARED_VERSION updated. It checks the latest release tag from cloudflare/cloudflared every 6 hours (and can be run manually), then opens a PR if a newer version is found.

It only supports one update at a time though, maybe make it just directly commit to main? There's a Cloudflared version that we missed. 2026.2.0

[Copilot]

Pull request overview

This PR adds a GitHub Actions workflow to automatically keep the CLOUDFLARED_VERSION variable in docker-bake.hcl up to date. The workflow runs on a schedule (every 6 hours) and can also be triggered manually; it fetches the latest release tag from cloudflare/cloudflared and opens an automated PR if a newer version is found.

Changes:

• Adds a new scheduled GitHub Actions workflow that checks for the latest cloudflare/cloudflared release
• Parses and updates the CLOUDFLARED_VERSION default value in docker-bake.hcl using awk
• Opens a PR via peter-evans/create-pull-request if the version has changed

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The github.rest.repos.getLatestRelease() API call can throw an exception (e.g., an HTTP 404 if there are no releases, or a network error), which would cause the step to fail with an unhandled error rather than a clean core.setFailed message. The if (!release?.data?.tag_name) guard only handles cases where the call succeeds but returns unexpected data — it doesn't catch errors thrown during the API call. Wrapping the call in a try/catch block and calling core.setFailed(error.message) in the catch handler would make error handling more robust and the failure message more informative.

Suggested change

	const release = await github.rest.repos.getLatestRelease({
	owner: 'cloudflare',
	repo: 'cloudflared'
	});
	if (!release?.data?.tag_name) {
	core.setFailed('Failed to resolve cloudflared release tag');
	return;
	}
	core.setOutput('latest_tag', release.data.tag_name);
	try {
	const release = await github.rest.repos.getLatestRelease({
	owner: 'cloudflare',
	repo: 'cloudflared'
	});
	if (!release?.data?.tag_name) {
	core.setFailed('Failed to resolve cloudflared release tag');
	return;
	}
	core.setOutput('latest_tag', release.data.tag_name);
	} catch (error) {
	core.setFailed(error && error.message ? error.message : String(error));
	}

[Copilot]

Writing externally controlled values directly into $GITHUB_OUTPUT using echo "key=$value" is a known GitHub Actions security concern. If $LATEST_TAG or $current_version contains a newline character (e.g., a maliciously crafted release tag), it could inject additional key=value pairs into $GITHUB_OUTPUT, potentially influencing downstream steps. The recommended mitigation is to use a multi-line delimiter approach with a random delimiter (the EOF pattern using $GITHUB_OUTPUT with heredoc syntax), for example:

echo "new_version<<EOF
$LATEST_TAG
EOF" >> "$GITHUB_OUTPUT"

But more practically, since these values should be single-line version strings, adding an explicit newline/whitespace check before writing would be a sufficient guard.

[Copilot]

When using the default GITHUB_TOKEN, pull requests created by peter-evans/create-pull-request will not trigger other GitHub Actions workflows (like docker-build.yml). This is a deliberate GitHub security restriction to prevent recursive workflow runs. Since the docker-build.yml workflow runs on every PR, the automated PR created by this workflow won't have CI checks run against it unless a person with write access closes and reopens the PR, or pushes a new commit to the branch. To make CI trigger automatically, a Personal Access Token (PAT) or a GitHub App token should be passed via the token parameter of this action.

[Erisa]

you can bypass this by setting docker-build to also be triggerable by workflow dispatch and running gh workflow run on the branch after the PR is made

https://github.com/Erisa/Cliptok/blob/68f6651f3423b4f00b4e460b2794157ffe4530ff/.github/workflows/append-lists-txt.yml#L53

[Erisa]

maybe make it just directly commit to main

I manually test every new version before I merge it to main, there have been several new versions which justified this practice because of various changes they made upstream with no regard for my image

[Erisa]

That testing could probably be automated nowadays though, I just don't feel like doing it myself. I build the image with docker bake, run it with --hello-world and then request the resulting tunnel URL several times to make sure it works.