starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[PR #974] [CLOSED] Bump meta action and always include latest #1783

New Issue
Closed
opened 2025-12-29 02:31:41 +01:00 by adam · 0 comments
adam commented 2025-12-29 02:31:41 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/juanfont/headscale/pull/974
Author: @snh
Created: 11/16/2022
Status: ❌ Closed

Base: main ← Head: bump-meta

📝 Commits (1)

  • f68aee7 Bump meta action and always include latest

📊 Changes

1 file changed (+5 additions, -2 deletions)

View changed files

📝 .github/workflows/release.yml (+5 -2)

📄 Description

  • read the CONTRIBUTING guidelines
  • raised a GitHub issue or discussed it on the projects chat beforehand
  • added unit tests
  • added integration tests
  • updated documentation if needed
  • updated CHANGELOG.md

A regression from https://github.com/juanfont/headscale/pull/959 is that the auto latest handling will intentionally avoid labeling a pre-release version, such as a beta, as latest.

I gather we want latest to point to the latest release regardless of if it is a pre-release like the previous behavior? If not, then the new behavior can be left alone, with only stable releases being tagged as latest. Though we'll probably want to create a new tag to use to reference the latest pre-release version for those who want to following along with development.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/juanfont/headscale/pull/974 **Author:** [@snh](https://github.com/snh) **Created:** 11/16/2022 **Status:** ❌ Closed **Base:** `main` ← **Head:** `bump-meta` --- ### 📝 Commits (1) - [`f68aee7`](https://github.com/juanfont/headscale/commit/f68aee7a144af6b66bd0ddbb22e5d5445fe3339d) Bump meta action and always include latest ### 📊 Changes **1 file changed** (+5 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `.github/workflows/release.yml` (+5 -2) </details> ### 📄 Description <!-- Please tick if the following things apply. You… --> - [x] read the [CONTRIBUTING guidelines](README.md#contributing) - [ ] raised a GitHub issue or discussed it on the projects chat beforehand - [ ] added unit tests - [ ] added integration tests - [ ] updated documentation if needed - [ ] updated CHANGELOG.md <!-- If applicable, please reference the issue using `Fixes #XXX` and add tests to cover your new code. --> A regression from https://github.com/juanfont/headscale/pull/959 is that the auto `latest` handling will intentionally avoid labeling a pre-release version, such as a beta, as `latest`. I gather we want `latest` to point to the latest release regardless of if it is a pre-release like the previous behavior? If not, then the new behavior can be left alone, with only stable releases being tagged as `latest`. Though we'll probably want to create a new tag to use to reference the latest pre-release version for those who want to following along with development. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2025-12-29 02:31:41 +01:00
adam closed this issue 2025-12-29 02:31:41 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1783
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?