search

teemtee / tmt

Test Management Tool
MIT License
76 stars 112 forks source link

Switch to autochangelog and specfile cleanup #2880

Open martinhoyer opened 3 weeks ago

martinhoyer commented 3 weeks ago

Pull Request Checklist

rpm changelog

%autochangelog

spec file cleanup

TODO

Upstream changelog

https://changie.dev/ ? Towncrier?

  • good integration with pyproject, pre-commit, rst docs..
  • used by pytest, pip, ...

action-gh-release? release-drafter?

  • reliance on github labels

Consensus is that there is no need to changelog manager, or dedicated changelog file.

LecrisUT commented 3 weeks ago

I'm also interested in changelog managers. Any experience with towncrier?

martinhoyer commented 3 weeks ago

I'm also interested in changelog managers. Any experience with towncrier?

No experience, sorry. Note that tmt does not want to use any sort of commit prefixes, incl. conventional commits, so tools that rely on those can be scratched from the conversation here right away.

Second note is that github labels are being used here and therefore could be used by some tool, or just .github/release.yml. They are however exclusive to github, so there could be 'vendor locking'

Last note is that tmt maintains changelog in RTD docs, but also in github releases page. Historically, it has been done using git log and copying it to gh, while github can generate it from PRs and their labels.

In any case, maybe it would be good to have a somehow conventional changelog file, which could be used as source of truth for the release automation. That why I thought to look into changie.dev, but if anyone have better suggestions, it would be great :)

lukaszachy commented 3 weeks ago

Last week packit changed the changelog - https://pagure.io/packaging-committee/issue/1339 - we should follow, right? Which means our rpm changelogs will be just Update to xxxxx ...

LecrisUT commented 3 weeks ago

No experience, sorry. Note that tmt does not want to use any sort of commit prefixes, incl. conventional commits, so tools that rely on those can be scratched from the conversation here right away.

From what I read about towncrier it doesn't use or rely on that. The workflow is to just write a file in a folder like .clangelo.d and all of those files will be collated to write into a file like Changelog.md.

It might not work well with specfile Changelog, but maybe that can be fixed with sed to eliminate the headers.

A less vendor-locking workflow would be to use that in conjunction with softprops/action-gh-release (using the body from Changelog.md). But I don't know if towncrier can integrate with the PR labels.

Which means our rpm changelogs will be just Update to xxxxx ...

This is configureable in changelog-entry action. Just need a script that can output the desired changelog text. Note that there is still no --dry-run functionality to see the output of this.

LecrisUT commented 3 weeks ago

Btw, how important do you consider the specfile changelog vs bodhi release notes? The latter is not accessible via packit, but there is an issue about it. What's nice about the latter is that it can use straightforward markdown, and it is the actual changes that the end-user sees.

martinhoyer commented 3 weeks ago

Last week packit changed the changelog - https://pagure.io/packaging-committee/issue/1339 - we should follow, right? Which means our rpm changelogs will be just Update to xxxxx ...

Just saw it today. So both packit default and %autochangelog would just have single 'Update to xxxx', yes.

It would probably make most sense to me to use rpmautospec convert command to switch to %autochangelog and leave the generated changelog file in Fedora dist-git. This way, the old entries will be still part of the rpms, while keeping the spec file clean in upstream repo.

martinhoyer commented 3 weeks ago

Btw, how important do you consider the specfile changelog vs bodhi release notes? The latter is not accessible via packit, but there is an issue about it. What's nice about the latter is that it can use straightforward markdown, and it is the actual changes that the end-user sees.

Good point, I believe bodhi should include a way for users to see the upstream changelog, but spec file should not be a place to store it, as per packaging guidelines.

lukaszachy commented 3 weeks ago

Should we add 'changelog.rst' file to this repo? Otherwise the "changelog" will be only in github release text and git log once the tmt.spec follows the packaging policy.

We have docs/releases.rst but that is just for highlights of the release AFAIK

LecrisUT commented 3 weeks ago

Should we add 'changelog.rst' file to this repo?

Common design is to have .. include:: ../Changelog.rst with appropriate start-after/end-before to synchronize the changelog. But I would recommend having it as Changelog.md so that it could be more readily used for Github release and Bodhi release notes when that comes up. But maybe with something like towncrier both formats can be generated :thinking:

martinhoyer commented 3 weeks ago

So I've checked some of the more popular changelog managers. Towncrier indeed looks like the best fit. Thanks @LecrisUT for the suggestion.

Other interesting tool is relese-drafter, which could be used if tmt decides to rely on github, github labels.

I'm thinking something like 

[tool.towncrier]
package = "tmt"
package_dir = "tmt"
filename = "doc/changelog.rst"
directory = "changelog/"  # or doc/news/ ?
title_format = "tmt {version} ({project_date})"
template = "changelog/_template.rst.j2"

(some of these might not be needed, not sure what's default)

Interesting implementation in buildbot: https://github.com/buildbot/buildbot/tree/master/newsfragments

Template ideas: pytest, pip

Any thoughts?

martinhoyer commented 2 weeks ago

@psss @lukaszachy ok so I've also removed %py_provides python3-tmt, as it's being generated automatically. Confirmed by testing with copr build and dnf provides python3-tmt.

Other thing to solve is how to deal with release commit, as packit is changing the version in specfile (note the 0.0.0), so we don't need to touch the specfile at all. The release workflow could therefore be just a tag (as other changes are not required for all releases, like adding new contributors). Pushing the tag could trigger a full-test, substituting the testing done in release pull request. WDYT?

lukaszachy commented 2 weeks ago

So if we pay attention to PR (read: add release note and change contributors if necessary) the release will need no commit, right?

martinhoyer commented 2 weeks ago

So if we pay attention to PR (read: add release note and change contributors if necessary) the release will need no commit, right?

if release note and contributors are not being changed, then no commit would be necessary, yes.

lukaszachy commented 2 weeks ago

Hm, how can one find test results from 'tag' ? Would it require checking packit dashboard?

martinhoyer commented 2 weeks ago

Hm, how can one find test results from 'tag' ? Would it require checking packit dashboard?

Not quite sure, I assume it could be packit release, instead of PR, yes. https://dashboard.packit.dev/projects/github.com/teemtee/tmt/ <- last one was 1.28.2, not sure what changed in 1.29

LecrisUT commented 2 weeks ago

Other thing to solve is how to deal with release commit, as packit is changing the version in specfile (note the 0.0.0),

If there are no actions to overwrite it, packit will always write the version from anitya (or such). Iirc the keep_changelog was preventing this automation.

The release workflow could therefore be just a tag

With propose_downstream? The release needs to be published after the tag is created to trigger it.

Also should add to top-level comment the steps to be done manually on downstream. Before a new release is pushed.

martinhoyer commented 2 weeks ago

Other thing to solve is how to deal with release commit, as packit is changing the version in specfile (note the 0.0.0),

If there are no actions to overwrite it, packit will always write the version from anitya (or such). Iirc the keep_changelog was preventing this automation.

The release workflow could therefore be just a tag

With propose_downstream? The release needs to be published after the tag is created to trigger it.

Also should add to top-level comment the steps to be done manually on downstream. Before a new release is pushed.

@LecrisUT talking about tmt release steps including a commit and PR https://tmt.readthedocs.io/en/stable/contribute.html#release

LecrisUT commented 2 weeks ago

I mean w.r.t. changing to %autochangelog. That step must be done once manually

martinhoyer commented 2 weeks ago

I mean w.r.t. changing to %autochangelog. That step must be done once manually

Hi @LecrisUT, sorry for my ignorance, I'm still not sure what you mean. rpmautospec convert?

LecrisUT commented 2 weeks ago

rpmautospec convert?

Yes I believe that's the command. I'm out of city this week, I can't double check. It's the command that moves all of the %changelog to the changelog file.

martinhoyer commented 2 weeks ago

rpmautospec convert?

Yes I believe that's the command. I'm out of city this week, I can't double check. It's the command that moves all of the %changelog to the changelog file.

Right, so the idea is to drop the old changelog completely. It should work without the file, but we have to double-check.
The consensus is that nobody will miss it and that it would be less than ideal, that it would be basically an upstream changelog and suddenly from one point it would switch to "update to xyz" entries. WDYT?