chore: automate release #120
Conversation
This reverts commit cdd385c.
|
|
config.json
Outdated
| @@ -0,0 +1,8 @@ | |||
| { | |||
There was a problem hiding this comment.
If we put it at the root of the repository we could maybe have a more descriptive name, wdyt?
There was a problem hiding this comment.
Do we release this actual repo or just the one generated ?
There was a problem hiding this comment.
We don't release it, it's just publicly available but we already have a few configs everywhere
There was a problem hiding this comment.
If we put it at the root of the repository we could maybe have a more descriptive name, wdyt?
I actually wrapped it with the key "release" for the reason. What do you think? Should we have a separate "release.config.json"?
There was a problem hiding this comment.
If you think of user use cases of this config, it's fine to keep it like that, otherwise yep it would make sense to have a release.config.json file only
config.json
Outdated
| @@ -0,0 +1,8 @@ | |||
| { | |||
There was a problem hiding this comment.
Do we release this actual repo or just the one generated ?
scripts/release/process-release.js
Outdated
| ].additionalProperties.packageVersion = versionsToRelease[lang].next; | ||
| } | ||
| }); | ||
| fs.writeFileSync('openapitools.json', JSON.stringify(json, null, 2)); |
There was a problem hiding this comment.
Can you use fs/promises pls ?
There was a problem hiding this comment.
these scripts already use a bunch of synchronous code like execa.commandSync. If we go with fs/promises, we need to go all in, but I'm not sure how it's beneficial.
config.json
Outdated
| @@ -0,0 +1,8 @@ | |||
| { | |||
There was a problem hiding this comment.
If you think of user use cases of this config, it's fine to keep it like that, otherwise yep it would make sense to have a release.config.json file only
| return; | ||
| } | ||
|
|
||
| if (commits.some((commit) => commit.message.includes('BREAKING CHANGE'))) { |
There was a problem hiding this comment.
We should note somewhere that introducing a breaking change requires our commit to contain it then
There was a problem hiding this comment.
It actually comes from https://www.conventionalcommits.org/
Do you think we need the mention somewhere in readme or contribution guide?
There was a problem hiding this comment.
Maybe a small md file in the doc folder describing commits and semantic titles, but this could be done in a later task (let's add it to our backlog still)
|
|
||
| dotenv.config(); | ||
|
|
||
| function getMarkdownSection(markdown: string, title: string): string { |
There was a problem hiding this comment.
Do you think it's worth having test for such scripts? I feel like the complexity requires it
There was a problem hiding this comment.
(not needed in this PR of course)
There was a problem hiding this comment.
If we have such code once or twice again, then we could setup jest, I guess. WDYT?
There was a problem hiding this comment.
Yep I think it would help us especially if we encounter edge cases in the future
There was a problem hiding this comment.
I think it's good for a first iteration of this release process, congrats!
Could you please add those 2 tickets to our backlog?
- Add doc about commits and semantic PR titles
- Write basic tests for this release process
Don't hesitate to do more testing on this repository (even if it floods the issue), so we can see how it behaves in detail.
🧭 What and Why
🎟 JIRA Ticket: https://algolia.atlassian.net/browse/APIC-297
Changes included:
yarn releasecreates a release issue.scripts/release/process-release.jsis run, and updates versions and changelogs.ScreenShot.2022-02-03.at.16.18.31-converted.2.mp4
TODO in another PRs
yarn generate ${lang}is failing inprocess-release.js. Investigate.Once done, we can prepare CI per repository.