chore: automate Changelog generation - #229
Conversation
5c13adc to
5ea6a3a
Compare
Gudsfile
added
documentation
e14989a to
ddf6e87
Compare
Tarektouati
left a comment
Tarektouati
left a comment
There was a problem hiding this comment.
Thanks for your PR.
Can you please document why you have chosen cliff instead of any other solution ?
We are changing a bit of paradigm.
Today, when a commit lands on main, depending on the directory impacted, everything is deployed in production.
I don't really understand why behind this PR, it also highlights some questions:
- How do we manage the monorepo life-cycle (a diagram can be helpful) ?
- Do we also generate new synthetics and upload them to HF on new releases ?
- Does it also deploy the blog ?
Important
We can get rid of .moon/tasks.yml and avoid writing bash, let not re-invent the wheel and let moon manage which application should be bumped
There was a problem hiding this comment.
What's the difference between .github/cliff-release.toml and .github/cliff-changelog.toml
There was a problem hiding this comment.
The only difference was the display of statistics. I combined the templates into a single file (cliff.toml) and managed the display of statistics via a variable.
There was a problem hiding this comment.
It doesn't work; it doesn't seem possible to have a variable. I suggest removing the statistics display; it wasn't necessary.
| pnpm version "$BUMP_STRATEGY" --no-git-tag-version | ||
| fi | ||
|
|
||
| if [[ -f "pyproject.toml" ]]; then | ||
| echo "• Python: pyproject.toml" | ||
| uv version --bump "$BUMP_STRATEGY" |
There was a problem hiding this comment.
suggestion: I would split this task and move it to each application app/moon.yml and synthetic-datasets/moon.yml
This way, you will be able to perform a moon run :bump-version on the concerned packages. without writing any bash
There was a problem hiding this comment.
That's right, I hadn't been able to do it any other way, but it turns out it's entirely possible. I modified the configuration so that app and synthetic-dataset have their bump-version command based on a given strategy.
I don't want to change the paradigm (with this PR). What's merged into main is sent to production. Today, our GitHub releases are mainly communications/milestones in our development. I don't want to change that for now, but we can talk about it again later. I'll take care of the documentation as soon as I have time! Thanks for proofreading. Regarding tasks and moon, I'll have a look, but it seems to me that this was the only solution I had to get a single version between projects based on commit names while taking into account the different package managers. I'll double-check and document that, too. |
Can you then rename the PR title to something Thanks for your time and work on this topic. |
Gudsfile
changed the title
8603919 to
6c36842
Compare
|
ce7b1f0 to
ada2349
Compare
2 participants
1️⃣ First
🔇 Problem
The release stage is manual and tedious.
🎹 Proposal
Automate it in a GitHub action. This GitHub action is launched manually by specifying the type of release to be made (
patch,minor, ‘major’) or by letting the action determine it based on the commits (auto).SECURITY.mdis updated🎶 Comments
🎤 Test
To test it, I ran the action several times on a test fork repo.