Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

changelog from commit hashes; changelogs from spec and BZ #175

Closed
wants to merge 3 commits into from
Closed

changelog from commit hashes; changelogs from spec and BZ #175

wants to merge 3 commits into from

Conversation

richm
Copy link
Contributor

@richm richm commented Aug 3, 2022

  • add support for creating changelogs for rpm releases
  • use git commit subjects for changelog if no version

@richm richm requested a review from nhosoi August 3, 2022 02:09
@richm
Copy link
Contributor Author

richm commented Aug 3, 2022

This goes with https://src.fedoraproject.org/rpms/linux-system-roles/pull-request/79

Pretty much each packaging method has a different way to generate the collection changelog :-(

  • galaxy - use release_collection.py - use each role CHANGELOG.md, or the git commits for commit hashes
  • Fedora rpm - generate from the %changelog
  • RHEL rpm and Automation Hub - generate using bz-manage.sh rpm_release $newversion - then edit CHANGELOG.md

@richm
add support for creating changelogs for rpm releases
0f4548c 
The function rpm_release will be used to generate the following
files:
* cl-md - the new entry to use for CHANGELOG.md
* cl-spec - the spec file %changelog section update
* git-commit-msg - the git commit message

The initial CHANGELOG.md is generated using spec_cl_to_cl_md.  Then
use rpm_release for subsequent releases.
@richm
use git commit subjects for changelog if no version
9f10c63 
If we are using the commit hash to build the collection, there will
not be a version and a corresponding changelog.  In that case, use
the git commit titles and list them as Bug Fixes.
* This will inevitably be wrong - there will be New Features
and Other Changes listed erroneously - but there is no way to
know
* When there is an actual release with a version and a changelog,
some of the changelog information will be duplicated - the new
release will list some of the old changelog items again.

I think this is a minor problem to have as long as releases using
commit hashes are rare, and the changelog isn't really used in
Galaxy anyway.
@nhosoi
Copy link
Contributor

nhosoi commented Aug 3, 2022

I'm playing with bz-manage.sh in this pr.
If I don't specify INCLUDE_CLONE=true, it returns 3 items.
If I do, then it returns none.

$ ITR=8.7.0 STATUS=POST INCLUDE_CLONE=true RPM_CL=true ./bz-manage.sh get_cl
$

Is it the expected behavior?

@richm
Copy link
Contributor Author

richm commented Aug 3, 2022

I'm playing with bz-manage.sh in this pr. If I don't specify INCLUDE_CLONE=true, it returns 3 items. If I do, then it returns none.

$ ITR=8.7.0 STATUS=POST INCLUDE_CLONE=true RPM_CL=true ./bz-manage.sh get_cl
$

Is it the expected behavior?

I think get_cl isn't useful any more - prefer to use rpm_release. Also INCLUDE_CLONE isn't really useful either - for rhel spec files, the changelog should contain only the BZ for the given release - so you cannot include the clone BZ in the spec %changelog - you already could not include the clone BZ in the git commit message.

@nhosoi
Copy link
Contributor

nhosoi commented Aug 3, 2022 •
edited
Loading

Thank you, @richm. Yes, rpm_release works nicely.
I noticed that it generates cl-md like this. Without clicking the links, it'd make the users wonder why there are two same bz's listed. I guess we have to include it in a good practice to add [9.1.0] and [8.7.0] to the bz summary...

- [logging - [RFE] Support startmsg.regex and endmsg.regex in the files inputs](https://bugzilla.redhat.com/show_bug.cgi?id=2112143)
- [logging - [RFE] Support startmsg.regex and endmsg.regex in the files inputs](https://bugzilla.redhat.com/show_bug.cgi?id=2112145)

Plus if you could clean up README - adding rpm_release and removing get_cl (?), I'd appreciate it.

@richm
Copy link
Contributor Author

richm commented Aug 3, 2022

Thank you, @richm. Yes, rpm_release works nicely. I noticed that it generates cl-md like this. Without clicking the links, it'd make the users wonder why there are two same bz's listed. I guess we have to include it in a good practice to add [9.1.0] and [8.7.0] to the bz summary...

- [logging - [RFE] Support startmsg.regex and endmsg.regex in the files inputs](https://bugzilla.redhat.com/show_bug.cgi?id=2112143)
- [logging - [RFE] Support startmsg.regex and endmsg.regex in the files inputs](https://bugzilla.redhat.com/show_bug.cgi?id=2112145)

It isn't supposed to do that - it is only supposed to look at BZ from only 1 ITR - so there should never be two of the same bugs from different releases with different BZ numbers.

Plus if you could clean up README - adding rpm_release and removing get_cl (?), I'd appreciate it.

I have split this PR into #177 and #176

@richm richm closed this Aug 3, 2022
@richm richm deleted the bz-to-cl branch August 3, 2022 18:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nhosoi nhosoi Awaiting requested review from nhosoi

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@richm @nhosoi