Conversation
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
size-limit report 📦
|
HiDeoo
left a comment
There was a problem hiding this comment.
Amazing, super impatient to try it out!
delucis
left a comment
There was a problem hiding this comment.
Looks fantastic @yanthomasdev! So excited to have this here having already admired it in docs — left two small comments, but apart from this, LGTM!
.github/workflows/lunaria.yml
Outdated
| shell: bash | ||
|
|
||
| - name: Generate Lunaria Overview | ||
| uses: yanthomasdev/lunaria-action |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
An alternative until the action is versioned could be to use a specific SHA maybe?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
Made it a SHA, let me know if we're good
There was a problem hiding this comment.
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.
Co-authored-by: Chris Swithinbank <swithinbank@gmail.com>
delucis
left a comment
There was a problem hiding this comment.
Thanks for making those changes @yanthomasdev — excited to see this in action! 🚀 🌚
* main: Update fa.json (withastro#1793) i18n(fr): update `resources/community-content.mdx` (withastro#1795) [ci] format i18n(ko-KR): update `community-content.mdx` (withastro#1794) [ci] format Adds Starlight in Next.js project video (withastro#1789) [ci] format i18n(ru): update translations (withastro#1783) i18n(id): Update getting-started.mdx (withastro#1778) Upgrade Lunaria and add Action (withastro#1768) [ci] format i18n(es): update `sidebar` (withastro#1767) i18n(pt-br): Update `getting-started.mdx` (withastro#1776) i18n(es): update `configuration` (withastro#1766) [ci] format Add TrueCharts to showcases (withastro#1773)
* main: (21 commits) Update fa.json (withastro#1793) i18n(fr): update `resources/community-content.mdx` (withastro#1795) [ci] format i18n(ko-KR): update `community-content.mdx` (withastro#1794) [ci] format Adds Starlight in Next.js project video (withastro#1789) [ci] format i18n(ru): update translations (withastro#1783) i18n(id): Update getting-started.mdx (withastro#1778) Upgrade Lunaria and add Action (withastro#1768) [ci] format i18n(es): update `sidebar` (withastro#1767) i18n(pt-br): Update `getting-started.mdx` (withastro#1776) i18n(es): update `configuration` (withastro#1766) [ci] format Add TrueCharts to showcases (withastro#1773) i18n(zh-cn): Update `sidebar.mdx` (withastro#1761) i18n(ko-KR): update `sidebar.mdx` (withastro#1760) i18n(fr): update `guides/sidebar` (withastro#1758) test: fix Windows path separator test issues (withastro#1759) ...
* main: (63 commits) Add translation for copy button (withastro#1788) Update astro-expressive-code (withastro#1720) Fix type inference for extended i18n schemas (withastro#1786) Fix TypeScript schema error when using project references (withastro#1777) Update fa.json (withastro#1793) i18n(fr): update `resources/community-content.mdx` (withastro#1795) [ci] format i18n(ko-KR): update `community-content.mdx` (withastro#1794) [ci] format Adds Starlight in Next.js project video (withastro#1789) [ci] format i18n(ru): update translations (withastro#1783) i18n(id): Update getting-started.mdx (withastro#1778) Upgrade Lunaria and add Action (withastro#1768) [ci] format i18n(es): update `sidebar` (withastro#1767) i18n(pt-br): Update `getting-started.mdx` (withastro#1776) i18n(es): update `configuration` (withastro#1766) [ci] format Add TrueCharts to showcases (withastro#1773) ...
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