feat: add publish workflow

[rtritto]

Fix #3154

[brillout]

I understand your previous question now.

Can we make https://github.com/vikejs/vike/tags and the CHANGELOG.md be the source of truth here?

[brillout]

(FYI we use https://github.com/brillout/release-me throughout many projects — not using it would be a little too disruptive.)

[rtritto]

I understand your previous question now.

Can we make https://github.com/vikejs/vike/tags and the CHANGELOG.md be the source of truth here?

The goal is to create GitHub releases in https://github.com/vikejs/vike/releases

On the creation of a GitHub release, I think you want to get the changelog by the version in CHANGELOG.md and not by commits, right?

(FYI we use https://github.com/brillout/release-me throughout many projects — not using it would be a little too disruptive.)

Should this feature be done here?

[brillout]

I understand your previous question now.
Can we make https://github.com/vikejs/vike/tags and the CHANGELOG.md be the source of truth here?

The goal is to create GitHub releases in https://github.com/vikejs/vike/releases

Yes I know.

I think you want to get the changelog by the version in CHANGELOG.md and not by commits, right?

Yes, the source of truth should ideally be CHANGELOG.md and not the commits (to keep things DRY).

(FYI we use https://github.com/brillout/release-me throughout many projects — not using it would be a little too disruptive.)

Should this feature be done here?

Let's first do it here and then we can see whether we want to move it to @brillout/release-me.

[rtritto]

Yes, the source of truth should ideally be CHANGELOG.md and not the commits (to keep things DRY).

Done

[brillout]

How about we run this workflow when the CHANGELOG.md file changes?

One issue is that I have to regularly modify CHANGELOG.md manually — can we make the release tags be fully synced (all versions!) whenever CHANGELOG.md changes? That'd be a bullet proof approach 💯

[rtritto]

Sure, I can do.

Should I leave also the manual trigger (workflow_dispatch)?

[brillout]

One issue is that I have to regularly modify CHANGELOG.md manually — can we make the release tags be fully synced (all versions!) whenever CHANGELOG.md changes? That'd be a bullet proof approach 💯

To be clear: what I mean is that whenever CHANGELOG.md changes => all GitHub releases are re-generated from scratch. Does GitHub allow this?

Should I leave also the manual trigger (workflow_dispatch)?

Ok why not.

[rtritto]

To be clear: what I mean is that whenever CHANGELOG.md changes => all GitHub releases are re-generated from scratch. Does GitHub allow this?

Done (it needs to be tested)

[brillout]

I think it can work indeed.

It seems to be working: https://github.com/vikejs/vike/releases — although it didn't sync all other releases. It should fully sync all releases with CHANGELOG.md every time it runs.

Can you PM me on discord or via email? I'll send you an API key with enough permissions for you to run the script locally.

[rtritto]

I think it can work indeed.

Top

It seems to be working: https://github.com/vikejs/vike/releases — although it didn't sync all other releases. It should fully sync all releases with CHANGELOG.md every time it runs.

There aren't other release.

Logic:

• create 1 new release (latest) if not exist
• update all releases (max 100)

Eg: when v0.4.256 will be released (CHANGELOG.md updated), the workflow:

• will create release v0.4.256
• will update release v0.4.255 (current it's a release), if changelog of v0.4.255 in CHANGELOG.md was changed

Can you PM me on discord or via email? I'll send you an API key with enough permissions for you to run the script locally.

IMO it's not necessary, what should I test?

[brillout]

create 1 new release (latest) if not exist

I see, makes sense from a release subscription POV.

But I think we can (and should?) retroactively publish all previous releases? Also nice to test the script.

[rtritto]

But I think we can (and should?) retroactively publish all previous releases? Also nice to test the script.

Agree, IMO we should create a new workflow (create all previous release using pagination per_page = 385 if it's supported) and trigger it (probably before the v0.4.255 needs to be deleted)

[brillout]

How about keeping it the same workflow but before proceeding with normal work we prepare for new repos: "if number of releases === 0" => publish all releases.

That way we can just copy & paste the workflow for other projects and it just works.

[brillout]

I just removed 0.4.255.

[rtritto]

How about keeping it the same workflow but before proceeding with normal work we prepare for new repos: "if number of releases === 0" => publish all releases.

That way we can just copy & paste the workflow for other projects and it just works.

Agree, in the current sync-releases.ts, we can temporary comment the POST/PATCH calls and then restore them after the creation of all releases

- if (releaseToCreate) {
-   // https://docs.github.com/en/rest/releases/releases#create-a-release
-   await githubRequest(`/repos/${owner}/${repo}/releases`, {
-     token,
-     method: 'POST',
-     body: releaseToCreate,
-   })
-   console.log(`Created release ${versionTag}`)
- }
- 
- for (const release of releasesToUpdate) {
-   // https://docs.github.com/en/rest/releases/releases#update-a-release
-   await githubRequest(`/repos/${owner}/${repo}/releases/${release.release_id}`, {
-     token,
-     method: 'PATCH',
-     body: { body: release.body },
-   })
-   console.log(`Updated release ${release.tag_name}`)
- }
+ // Create release from oldest to newest, so that the release list
+ // is sorted by creation date in the same order as the changelog sections
+ const allTagReleasesToCreate = Object.keys(sections).reverse()
+ for (const tagName of allTagReleasesToCreate) {
+   await githubRequest(`/repos/${owner}/${repo}/releases`, {
+     token,
+     method: 'POST',
+     body: {
+       name: tagName,
+       tag_name: tagName,
+       target_commitish: defaultBranch,
+       body: sections[tagName]
+     }
+   })
+   console.log(`Created release ${tagName}`)
+ }

WDYT, can I do the commit?

[brillout]

I'd rather write the logic once now and be done with it. Zero manual procedure:

That way we can just copy & paste the workflow for other projects and it just works.

That's going to neat, e.g. for vike-react

[rtritto]

Done

[brillout]

There seem to be some parsing issue: https://github.com/vikejs/vike/releases/tag/v0.1.1

[rtritto]

There are some error in CHANGELOG.md: versions <= 0.1.0 use # [ instead of ## [ (eg. # [0.1.0] instaed of ## [0.1.0])

IMO you have to:

• fix CHANGELOG.md, from # [ to ## [
• delete all releases
• start workflow

[rtritto]

Do you want a PR to fix CHANGELOG.md?

[brillout]

The best would be somewhat lenient:

• https://github.com/brillout/telefunc/blob/a5eccf5a60436906be628132cecd809585f4c4c7/CHANGELOG.md#L227
• https://github.com/brillout/telefunc/blob/a5eccf5a60436906be628132cecd809585f4c4c7/CHANGELOG.md#L1180

I.e.:

• If line doesn't contain x.y.z number => skip it
• ## and # treated the same

Also an ability to dry-run the script would be awesome. Let's us test the script without doing API requests.

[rtritto]

Done

[brillout]

• Let's add a test for that last change
• Let's add a test for a couple of first hundreds of LoC of Vike's changelog. Same for Telefunc, vike-vue, vike-solid, and vike-solid
• Let's add dry-run

[brillout]

@rtritto Any luck? Polishing this PR makes a huge difference — if we can merge it once and then forget about it that'd be the best.

[rtritto]

This is LGTM, you can go ahead as you like

[brillout]

I'd rather merge after this:

• feat: add publish workflow #3157 (comment)

Contribution welcome. We have a lot of higher priorities — we unfortunately cannot afford working on low-priority things.