search

tailscale / tailscale-qpkg

Package Tailscale client in QPKG
MIT License
457 stars 38 forks source link

Create automatically new release on new Tailscale version #14

Closed ivokub closed 3 years ago

ivokub commented 3 years ago

For the build workflow, I already fetch the latest Tailscale tag automatically. This should be automated and a new release created on a new Tailscale tag.

guidoiaquinti commented 3 years ago

What about directly fetching the upstream version at build time without having to do a new release every time upstream creates one?

➜  ~ curl --silent "https://api.github.com/repos/tailscale/tailscale/releases/latest" | jq -r .tag_name
v1.8.1

Edit: I now see you already used ☝️ in workflows/build.yml

ivokub commented 3 years ago

Yes, fetching the latest upstream Tailscale version and building package with it can be done exactly as you noted.

However, for creating automatic releases, we would need to have an Action which periodically polls latest upstream Tailscale version, compares it against the releases in this repository and if there is no such release, creates a new release. The workflow workflows/build_release.yml should then pick up the new release and build assets for it.

I am not yet sure if Actions themselves are flexible enough to get to where we need. Another option would be to have some simple script which does the same and run it with Actions periodically. I have tried to get it working in the past, but I was unsuccessful :(

Do you have any suggestions which path to take? I could try again.

guidoiaquinti commented 3 years ago

Thanks for the additional context!

Do you have any suggestions which path to take?

I don’t think this repo should cut a new release when the upstream repo changes. My view is that as default we should always build the latest available upstream release while by passing a custom env variable (e.g. TSTAG or TSCOMMIT) we could let users to build and package a specific version they want.

Version tags should be specific to features related to this repo (e.g. “fixed binary version”, “users can now target a specific GOARCH package”, etc..)

ivokub commented 3 years ago

I added a script which checks the upstream Tailscale version and updates the version information in the repository. Additionally, I added a new workflow, which runs this script daily and commits the changes and adds a tag if there is an upstream update.

I in general agree that releases in this repository should reflect changes to features of this repository, but I think that the users coming here expect to find the latest working package and do not care much about other features this repository provides. Providing too many different tailscale/tailscale*ivokub/tailscale-qpkg options would confuse them. The same approach is also used in tailscale/tailscale-synology and tailscale/tailscale-android repositories.

guidoiaquinti commented 3 years ago

Make sense, thanks for the additional context!