Upgrade Lunaria and add Action

[yanthomasdev]

Description

This PR updates our Lunaria version to the latest version and adds its brand-new GitHub Action to the repository.

Now, all PRs that affect translations (source content changes, translation PRs) will receive a comment with a few insights, like these:

I've tested the Action before in a fork, so things are not supposed to blow up🤞 - More info on: GitHub Action - Lunaria Docs

[changeset-bot]

⚠️ No Changeset found

Latest commit: ca1f6a1

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
starlight	✅ Ready (Inspect)	Visit Preview	Apr 22, 2024 9:31pm

1 Ignored Deployment

Name	Status	Preview	Updated (UTC)
starlight-i18n	⬜️ Ignored (Inspect)		Apr 22, 2024 9:31pm

[astrobot-houston]

size-limit report 📦

Path	Size
/index.html	6.1 KB (0%)
/_astro/*.js	21.57 KB (0%)
/_astro/*.css	13.45 KB (0%)

[HiDeoo]

Amazing, super impatient to try it out!

[delucis]

Looks fantastic @yanthomasdev! So excited to have this here having already admired it in docs — left two small comments, but apart from this, LGTM!

[delucis]

Can we add a version number here? That way we don’t get caught out if the Lunaria action is updated in a breaking way.

[yanthomasdev]

I think we're actually missing the @main here to target the branch. Currently, there are no "versions" for the Action since it interacts with the Lunaria version present in the repo itself, it does use some of Lunaria APIs but those are very unlikely to have breaking changes anytime soon.

[HiDeoo]

An alternative until the action is versioned could be to use a specific SHA maybe?

[yanthomasdev]

We could do this as well if we want to be extra cautious. One thing that makes me opt for a branch is also being able to update with new features without having to update the branch in all the repos

[delucis]

Yeah the branch doesn’t buy us much protection from breaking changes or (worst case scenario) dangerous code being pushed to main in Lunaria. I think tying to SHA like HiDeoo suggested makes sense here.

It might seem counterintuitive but sometimes some friction can be good here. For example, let’s say you decide Lunaria needs some change that will improve things, but break the current action config — maybe it now needs some new option, or something changed name etc. If everyone is using the unqualified action, you now have a situation where you know pushing that change will break everyone and your only way to avoid that would be to proactively go and 1) lock all users to the current version with PRs, 2) then merge your breaking changes, then finally 3) unlock those users again to upgrade with new PRs.

Following a versioned release flow (or in its absence using a SHA) means users can intentionally upgrade and you can iterate knowing you won’t be causing chaos. (Long term proper semantic versioning is the best of both worlds: breaking change protection PLUS timely updates for safe changes.)

[yanthomasdev]

Made it a SHA, let me know if we're good

[HiDeoo]

Also sharing here if it can helps, as I personally always found the actions recommended release strategy using moving git tags to be a bit tedious, this action to help with this by automatically moving the tags.

[delucis]

Thanks for making those changes @yanthomasdev — excited to see this in action! 🚀 🌚