Skip to content
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.

Sign up for GitHub

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

Upgrade Lunaria and add Action #1768

Merged
merged 5 commits into from
Apr 23, 2024
Merged

Upgrade Lunaria and add Action #1768

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1969613
Upgrade Lunaria and add Action
yanthomasdev Apr 18, 2024
8cf5a5b
Run only in the docs
yanthomasdev Apr 22, 2024
71e7753
Update lunaria.yml
yanthomasdev Apr 22, 2024
5b83b89
Merge branch 'main' into lunaria-upgrade-and-action
yanthomasdev Apr 22, 2024
ca1f6a1
Use SHA
yanthomasdev Apr 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions .github/workflows/lunaria.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
name: Lunaria

on:
# Trigger the workflow every time a pull request is opened or synchronized at the target `main` branch
pull_request_target:
types: [opened, synchronize]
branches: [main]

yanthomasdev marked this conversation as resolved.
Show resolved Hide resolved
# Allow this job to clone the repository and comment on the pull request
permissions:
contents: read
pull-requests: write

jobs:
lunaria-overview:
name: Generate Lunaria Overview
runs-on: ubuntu-latest

steps:
- name: Checkout
uses: actions/checkout@v4
with:
# Necessary for Lunaria to work properly
# Makes the action clone the entire git history
fetch-depth: 0

- name: Setup PNPM
uses: pnpm/action-setup@v3

- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
cache: pnpm

- name: Install dependencies
run: pnpm install
shell: bash

- name: Generate Lunaria Overview
uses: yanthomasdev/lunaria-action
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

with:
token: ${{ secrets.FREDKBOT_GITHUB_TOKEN }}
working-directory: docs
3 changes: 2 additions & 1 deletion docs/lunaria.config.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,8 @@
"files": [
{
"location": "src/content/docs/**/*.{md,mdx}",
"pattern": "src/content/docs/@lang/@path"
"pattern": "src/content/docs/@lang/@path",
"type": "universal"
}
],
"dashboard": {
Expand Down
2 changes: 1 addition & 1 deletion docs/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@
"dependencies": {
"@astro-community/astro-embed-youtube": "^0.4.4",
"@astrojs/starlight": "workspace:*",
"@lunariajs/core": "^0.0.25",
"@lunariajs/core": "^0.0.32",
"@types/culori": "^2.0.0",
"astro": "^4.3.5",
"culori": "^3.2.0",
Expand Down
Loading
Loading