-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Latest Version by Default #28
Comments
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:
|
Does 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 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 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 #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.The text was updated successfully, but these errors were encountered: