Add workflow for automatic Cloudflared updates

[elcajon]

Proposed Changes

This PR adds a workflow for automating upstream issued updates.

Changes:

• Outsourcing cloudflared version information from build.sh to cloudflared_version.json
• Updating build.sh to read version from cloudflared_version.json file
• Copying cloudflared_version.json file to Docker image
• Adding workflow file cloudflared_release.yaml

Workflow logic:

• Checkout local repository
• Get latest (stable) cloudflared release from Github
• Compare current version to latest version
• Update cloudflared_version.json
• Commit, push and create PR

Related Issues

(Github link to related issues or pull requests)

[brenner-tobias]

Great suggestion. I thought for a moment there might be an easier solution using Dependabot, but I guess this does not work since we are not using any package manager here. We could misuse Docker for that (since Cloudflared is only available as a docker file), but I think this would not make it easier. So unless you have another idea with dependabot, feel free to merge.

[elcajon]

Dependabot is currently still somewhat limited in terms of supported formats. I think when using Dockerfiles updates we will also need a separate logic.
The only thing we need to consider here is that automatically generated PRs don't trigger any further workflows (because of the use of GITHUB_TOKEN). I suggest as a workaround to close the PR briefly and then reopen it to start the workflows.
Check action documentation for further information on the workflow trigger logic.

[felipecrs]

I think that if we use "pull_request_target" instead of "pull_request", it can use the GITHUB_TOKEN.

[elcajon]

I think that if we use "pull_request_target" instead of "pull_request", it can use the GITHUB_TOKEN.

I checked the GitHub documentation on this trigger event, which outlines:

This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.

Have you get this running in the context of Docker build repositories with pull_request_target?

[felipecrs]

This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.

This is because of security. pull_request_target uses the workflow file from main, while the rest of the repo is taken from the pull request. That's why it's considered unsecure to do things with the code.

But I don't think it would be a problem for this.