ci: autogenerate changelog #330

janbuchar · 2024-07-19T15:09:52Z

closes Generate changelog from the commit messages #18

janbuchar · 2024-07-19T15:17:02Z

Made this a draft, I'll try to update this so that it works with workflow_dispatch

janbuchar · 2024-07-23T21:05:57Z

@vdusek @B4nan I haven't run this yet, I imagine there will be quite some hotfixing. Also version bumps are still quite spaghettific.

janbuchar · 2024-07-23T21:27:04Z

.github/workflows/_publish_to_pypi.yaml

The release artifacts seem bordeline useless - I hope nobody installs packages by downloading .whl files from github. If someone tried, dependency management would be hell. Are there any points against dropping them?

It is nice that we make tags for beta releases, but shouldn't we make github pre-releases instead?

Github pre-releases can swamp the release list page - see https://github.com/vercel/next.js/releases. You can use the prerelease:false search filter, but still.

I don't like to pollute anything else than the package manager for prereleases, I would remove the git tags as well (I did in some repositories already, e.g. in the JS monorepos we maintain), since I can't justify adding tags to every single commit to master.

Sure, just removing the git tags is also an option. We'd lose a bit of traceability (what changed between those betas?), but if we keep releasing often, nobody will care 🙂

If every commit to master is a beta, it should be pretty clear what changed between those betas.

What I mean is, if you have 0.42.2b73 installed, how do you look up what changed between that and the current 0.42.2b91 if there are no tags?

You would check the git history, but I agree its a chore to find what commit triggered what version (since you need to go through the CI logs). For me this is not something I would optimize for, we don't want users to be on the beta releases (only if they don't want to wait for us to do a stable release).

To me, it's just adding (a lot of) noise, for a very low value, but that does not mean I don't see any value - so if you guys want to keep the git tags there, let's keep them (and we can remove later if you change your mind, heh). I would skip the GH releases, that really feels too much - they would always contain a single item only.

Clarification, it's not every commit, the chore/docs commits are ignored.

I don't see a problem with that either, we would ignore those commits in the changelog too.

I'm fine with removing the beta tags - every simplification of that workflow counts.

Can I also not upload the release artifacts? (see the argument above)

You mean completely, including for stable releases? I guess its fine too, I also don't think people use them, and we can revert this if we hear from someone who would like to do so.

Regarding the beta tags - I'm ok with both keeping/removing them, so do as you prefer.

B4nan · 2024-07-24T09:04:03Z

.github/workflows/run_release.yaml

+          - auto
+          - custom


i would like to be able to trigger major/minor/patch specifically (just like we have it in the js crawlee) instead of relying on the git messages. some feature commits are not really worth a feature release (but you want them in the changelog and its just wrong to call them fixes just because of this)

Thing is, I'm not aware of a way of doing this with git-cliff specifically. I know this is a weak excuse, but I really liked the idea of letting git-cliff bump our versions without having to search for yet another utility.

Can we open a new issue for this? In the meantime, we can always use the custom mode.

Also, kinda off topic, but some people (such as @netmilk IIRC) would tell you that attaching emotional value to version numbers is wrong and you should just follow the semantic versioning spec like a robot. Every side of the argument has its points IMO.

...it looks like poetry version could also work for us.

How is this about git cliff? You use that to generate changelog between two git tags or commit hashes I'd guess, or its not working that way? The option I am after would only let you decide the version bump manually instead of relying on the git messages.

This is how - it has a flag that outputs the new semver based on commits since the last tag. I used it because it was handy. The workflow_dispatch can also accept a custom version number, which will be used directly.

I agree with @B4nan on this.

I don't think we're in any kind of disagreement. You can already set a custom version, can't that be used to achieve the same thing you could do with a patch/minor/major toggle?

The points about marketing and fixing previous mistakes are both valid. While we're at the topic, can we not fix incorrect commit types by push-forcing to master? I'm aware there are tradeoffs, it's an honest question about which ones we picked.

You can already set a custom version, can't that be used to achieve the same thing you could do with a patch/minor/major toggle?

Yes, it can be used for the same, but is less ergonomic. It means you need to check the version you are on, instead of just releasing the next bump based on the type. You add another possibility for the user to screw it up. I want something in between, not full auto, but not full custom. We are using this for quite some time in crawlee, and it feels really nice, so I would like to see it the same way - especially because we want to port this setup to other repositories in the long run.

While we're at the topic, can we not fix incorrect commit types by push-forcing to master?

Force push to master is a big no-no, especially in open-source repositories. This can piss all the other ~~maintainers~~ collaborators off easily, seen that many times in nette community, as the author liked to do this a lot. You break their local versions since you change commit hashes.

There are exceptions to everything, but I can justify force pushing only for the very last commit done by yourself, within very short time window after they were pushed (lets say minutes).

Yes, it can be used for the same, but is less ergonomic. It means you need to check the version you are on, instead of just releasing the next bump based on the type. You add another possibility for the user to screw it up. I want something in between, not full auto, but not full custom. We are using this for quite some time in crawlee, and it feels really nice, so I would like to see it the same way - especially because we want to port this setup to other repositories in the long run.

Sure, I'm in favor of that, but I'd prefer to do that after this PR is merged and tested. Autogenerated changelogs and triggering releases via workflow_dispatch are enough of a milestone IMO.

Force push to master is a big no-no, especially in open-source repositories. This can piss all the other maintainers collaborators off easily, seen that many times in nette community, as the author liked to do this a lot. You break their local versions since you change commit hashes.

Haha, I remember that. I agree that the negative impact on contributors is not worth it.

Ok, I am fine merging this without it, that's fair. But I would like to see it implemented before next release.

vdusek · 2024-07-24T09:37:18Z

.github/workflows/run_release.yaml

@@ -36,20 +36,109 @@ jobs:
    name: Check whether to release
    if: |
      github.event_name == 'workflow_dispatch' ||
-      github.event_name == 'release' ||
      (
        github.event_name == 'push' &&
        !startsWith(github.event.head_commit.message, 'docs') &&


Suggested change

!startsWith(github.event.head_commit.message, 'docs') &&

!startsWith(github.event.head_commit.message, 'doc') &&

the commit prefix is called docs: not doc:

https://www.conventionalcommits.org/en/v1.0.0/#summary

Oh, I based this on what we have in cliff.toml, in that case, it should be updated there from doc to docs.

I suspect that git-cliff only puts ^doc in the default configuration to catch both doc: and docs: so that they please everyone 😄

The newly added PR title check should prevent any errors anyway, but I can update cliff.toml too.

janbuchar · 2024-07-24T09:44:41Z

It'd be great to have Check PR title workflow here as well.

Sure, added.

vdusek

Also please remove check-changelog-entry from .pre-commit-config.yaml.

.github/workflows/run_code_checks.yaml

.github/workflows/check_pr_title.yaml

vdusek · 2024-07-24T09:54:08Z

.github/workflows/run_release.yaml

+          - auto
+          - custom


I agree with @B4nan on this.

vdusek

Let's see how it's gonna work, otherwise good job!

Add cliff.toml and regenerate CHANGELOG.md

ffa8208

janbuchar added the t-tooling Issues with this label are in the ownership of the tooling team. label Jul 19, 2024

janbuchar requested review from vdusek and B4nan July 19, 2024 15:09

janbuchar added 2 commits July 19, 2024 17:10

Update changelog on each change

9c00f53

Remove changelog entry check

fd83fae

janbuchar marked this pull request as draft July 19, 2024 15:15

janbuchar added 2 commits July 19, 2024 17:42

Skip CI on changelog update commit

9f1adbd

Merge remote-tracking branch 'origin/master' into autogenerate-changelog

4d40150

github-actions bot assigned janbuchar Jul 22, 2024

github-actions bot added this to the 94th sprint - Tooling team milestone Jul 22, 2024

Hide the whole release process behind workflow_dispatch

9025a53

janbuchar marked this pull request as ready for review July 23, 2024 21:03

Fix removing beta tags

06ae489

janbuchar commented Jul 23, 2024

View reviewed changes

janbuchar added 3 commits July 24, 2024 00:14

Merge remote-tracking branch 'origin/master' into autogenerate-changelog

51c4d91

Better header for unreleased versions

abbafda

Handle breaking commits in 0.x.y correctly

8d6d87e

vdusek mentioned this pull request Jul 24, 2024

fix: Warn instead of crashing when an empty dataset is being exported #342

Merged

B4nan reviewed Jul 24, 2024

View reviewed changes

vdusek reviewed Jul 24, 2024

View reviewed changes

This comment was marked as resolved.

Sign in to view

Add Check PR Title workflow

0cb09ef

vdusek requested changes Jul 24, 2024

View reviewed changes

janbuchar added 3 commits July 24, 2024 13:37

Fix indentation

ba37ba8

Be more explicit in cliff.toml

77bdecb

Remove changelog check from pre-commit config

5938adf

Do not upload artifacts, do not make tags for beta packages

ac8389d

janbuchar requested a review from vdusek July 24, 2024 11:57

vdusek approved these changes Jul 24, 2024

View reviewed changes

Remove changelog checkbox from PR checklist

9cae575

janbuchar mentioned this pull request Jul 24, 2024

Finalize release process #356

Closed

7 tasks

Changelog facelift

a521821

janbuchar merged commit 9a76ac4 into master Jul 26, 2024
12 of 20 checks passed

janbuchar deleted the autogenerate-changelog branch July 26, 2024 13:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ci: autogenerate changelog #330

ci: autogenerate changelog #330

janbuchar commented Jul 19, 2024

janbuchar commented Jul 19, 2024

janbuchar commented Jul 23, 2024

janbuchar Jul 23, 2024

janbuchar Jul 23, 2024

B4nan Jul 24, 2024

janbuchar Jul 24, 2024 •

edited

Loading

B4nan Jul 24, 2024

B4nan Jul 24, 2024

janbuchar Jul 24, 2024

janbuchar Jul 24, 2024

B4nan Jul 24, 2024

vdusek Jul 24, 2024

B4nan Jul 24, 2024

janbuchar Jul 24, 2024

janbuchar Jul 24, 2024

B4nan Jul 24, 2024

janbuchar Jul 24, 2024

vdusek Jul 24, 2024

janbuchar Jul 24, 2024

B4nan Jul 24, 2024 •

edited

Loading

janbuchar Jul 24, 2024

B4nan Jul 24, 2024

vdusek Jul 24, 2024

B4nan Jul 24, 2024

vdusek Jul 24, 2024

janbuchar Jul 24, 2024

This comment was marked as resolved.

janbuchar commented Jul 24, 2024

vdusek left a comment

vdusek Jul 24, 2024

vdusek left a comment

	!startsWith(github.event.head_commit.message, 'docs') &&
	!startsWith(github.event.head_commit.message, 'doc') &&

ci: autogenerate changelog #330

ci: autogenerate changelog #330

Conversation

janbuchar commented Jul 19, 2024

janbuchar commented Jul 19, 2024

janbuchar commented Jul 23, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janbuchar Jul 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

B4nan Jul 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as resolved.

janbuchar commented Jul 24, 2024

vdusek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vdusek left a comment

Choose a reason for hiding this comment

janbuchar Jul 24, 2024 •

edited

Loading

B4nan Jul 24, 2024 •

edited

Loading