Open johannesdrescher opened 2 years ago
When people specify a particular commit in their YAML, I don't think the behavior of the action at that commit should change. It shouldn't shift over time to use new Tailscale releases.
@DentonGentry That makes sense. How about automating the replacement of the default value to always use the latest version? I wrote the code for this yesterday but discarded it because the dynamic default seemed simpler. But with this solution there would be a new commit for every Tailscale release.
I agree that the static version should be advanced every release rather than always using the latest version.
IMO this github action could use a Github workflow of its own that does two things:
release
on merge to main
version
in action.yml
with the new release versionDoes anyone know if this has been addressed at all?
I do not expect to implement this. People using this action are free to pass in a version
and increment it as often as they like, but I expect the version in the base YAML to remain unchanged for long periods of time and only change when we have a meaningful reason to do so. The Action currently uses 1.42.0 because that allows use of OAuth credentials and not require authkey rotation every 90 days.
We release client updates every 4 weeks, with patch releases between. Almost none of the changes in those client releases impact use of Tailscale in an environment for CI runners. Features added for VPN and human use of the system mostly do not apply.
We maintain compatibility with Tailscale releases going far back in time. At present we still maintain interoperability with Tailscale version 0.9. A GitHub runner with Tailscale 1.42 is compatible with other nodes on the tailnet running different versions.
GitHub's hosted actions runners tend to result in mysterious behaviors, but whenever anything changes these behaviors are attributed to the thing which changed most recently. Whenever we change this GitHub action we spend the next week or two fielding support tickets for every GitHub hiccup and claiming that Tailscale must have broken it because Tailscale is the only thing which changed.
I disagree on some of the logic here. This is backwards to how most other actions work. Most other actions default to using the latest version of a program and use the version option if do want to stay at a specific version. You don't have to change the action itself to track the latest version, most others use some logic to query the latest version EG curl -s "https://pkgs.tailscale.com/stable/?mode=json" | jq -r .Version
as in #131.
If you do stay with this current behavior this issue should be closed as WONTFIX and the related PRs should be closed, and the behavior should be documented. I've bugged our rep several times about this behavior, I don't believe they knew that was the expected behavior which is why I do believe there's been a couple merged PRs to update the version but no release.
The behavior mentioned in the comment https://github.com/tailscale/github-action/issues/28#issuecomment-1838519627. Is now officially documented https://tailscale.com/kb/1276/tailscale-github-action?q=action#tailscale-github-action-version
The behavior mentioned in the comment #28 (comment). Is now officially documented https://tailscale.com/kb/1276/tailscale-github-action?q=action#tailscale-github-action-version
Very sensible update! I agree this should be closed as a won't fix issue.
Instead of hard coding a default version, why not use the latest version by default? This would make the action simpler to use and reduce the need for future maintenance.
GitHub Actions does not allow input defaults to be assigned dynamically. So this would have to be done by setting the
version
input to not required and the default to an empty string and by then inserting the latest version before download if theversion
input is left unspecified.