ci: Update the next tag when a alpha/beta release is published

[Princesseuh]

Changes

This makes it so astro@next always point to the latest release of the next branch. This makes it a bit more easier for users to update between alphas to beta etc as they can always just npm install astro@next. In the future, this could also power nightly or canaries versions perhaps.

Right now this only updates astro, it could be extended to support every integration if we deem it necessary

Testing

It won't work, it's GitHub Actions

Docs

N/A

[changeset-bot]

⚠️ No Changeset found

Latest commit: 70e5848

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[bluwy]

Isn't next an internal term we use that encompasses alpha and beta, and that users should really only know about alpha and beta? Otherwise introducing another next could be confusing as to which is what, I think me a second too 🤔

If they're migrating from the alpha to the beta, I think it's important for them to opt-in to the beta with astro@beta instead of astro@next. It's also confusing that astro@next would install a .alpha- or .beta- versions, and not .next-.

[Princesseuh]

Isn't next an internal term we use that encompasses alpha and beta, and that users should really only know about alpha and beta? Otherwise introducing another next could be confusing as to which is what, I think me a second too 🤔

If they're migrating from the alpha to the beta, I think it's important for them to opt-in to the beta with astro@beta instead of astro@next. It's also confusing that astro@next would install a .alpha- or .beta- versions, and not .next-.

next is already a public documented term, users need to do pnpm create astro -- --ref next to get the beta for new projects, since it refers to the branch. I think being able to always use next makes more sense than needing to learn "next for create-astro, at version for npm"

[bluwy]

Perhaps we could redirect --ref alpha and --ref beta to next internally so we don't have to expose next? It's also odd that we default to --ref latest where in practice it should be --ref main. latest here seems to imply that the intent was the latest npm tag, but we then created a latest branch for it.

I guess my proposal is:

1. In main, auto redirect --ref alpha and --ref beta to next
2. In next (major), we restrict --ref to only allow accepting latest, alpha, and beta (--tag would've been a better name too 🤔)

I think it's valuable still to hide next as much as possible so we don't leak out the confusion between branches and npm tags.

[Princesseuh]

--ref here refers to which branch to download the template from, that's why it's named that way, it can also be used for third-party repos. We could probably redirect it, but it's kinda weird?

[matthewp]

@bluwy The --ref argument refers to git refs, which are just aliases for a commit. You can pass any valid ref there, whether it's a branch name or a tag, I think you can even pass a commit hash.

We shouldn't overload the meaning of ref to mean npm tags instead. Git refs and npm tags are different things.

npm tags don't have any actual meaning to them. They are just pointers to a version. You can name them anything you want, it doesn't matter that next points to [email protected].

I can see there being slight confusion about passing --ref next, but this is required, because create-astro deals with git branches, not with npm tags. If we wanted to "fix" this confusion it would be to move the next branch into a branch named beta instead. Is that worth it though?

[bluwy]

I get how ref and npm tags work. My point is that it feels like we're mixing them up. When we announce the alpha or the beta, users shouldn't encounter another term "next" even if that means technically pointing to the branch we're working on. In practice, they shouldn't have to know what branch we're working on. If we go ahead and establish a "next" npm tag, I think that overloads the "next" term more.

--ref here refers to which branch to download the template from, that's why it's named that way, it can also be used for third-party repos. We could probably redirect it, but it's kinda weird?

Checking the code, I think --ref only refers to Astro's branch/commit/etc. --template is used for third-party repos. Third party repos have to specify --template user/repo#my-branch

astro/packages/create-astro/src/actions/template.ts

Lines 74 to 82 in e748c48

	export function getTemplateTarget(tmpl: string, ref = 'latest') {
	if (tmpl.startsWith('starlight')) {
	const [, starter = 'basics'] = tmpl.split('/');
	return `withastro/starlight/examples/${starter}`;
	}
	const isThirdParty = tmpl.includes('/');
	if (isThirdParty) return tmpl;
	return `github:withastro/astro/examples/${tmpl}#${ref}`;
	}

If we wanted to "fix" this confusion it would be to move the next branch into a branch named beta instead. Is that worth it though?

We can setup the same way we sync the main branch to the latest branch:

astro/.github/workflows/main.yml

Lines 63 to 77 in e748c48

	update:
	name: Update the latest branch
	needs: check_for_update
	if: needs.check_for_update.outputs.run_job == 'true'
	runs-on: ubuntu-latest
	steps:
	- uses: actions/checkout@v4
	with:
	fetch-depth: 0
	- name: Push
	uses: ad-m/github-push-action@master
	with:
	github_token: ${{ secrets.GITHUB_TOKEN }}
	branch: latest

In the future, this could also power nightly or canaries versions perhaps.

I think we already have pkg.pr.new to handle that

---

Taking a step back, I think my proposal is indeed kinda wild. But I do like the idea of syncing the next branch to the beta branch.

But also like most of my comments, I don't think it's the end of the world if we want to go with this PR. I was thinking it's worth reducing the confusion a bit.

[matthewp]

I do agree that using the term beta would be an improvement here. I don't think it would be too much work just to change the branch to be beta to match. That seems slightly better than adding stuff to our workflow that's going to have to be removed later.

[Princesseuh]

Closing since it seems like we won't do this. Not sure how fun it'd be to migrate from next to beta right now with the in-flight PRs, but something to try for later.