Project

Profile

Help

Task #4983

Add changelog check to the Travis configuration tool

Added by bmbouter 8 months ago. Updated 3 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Plugin Template
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 57

Description

The Travis configuration tool should look at the commit message to know which issue this story is related to. It should then check redmine for a few things.

If it's a story ensure there is a CHANGES/<num>.feature
If it's an issue ensure there is a CHANGES/<num>.bugfix
If it has the documentation tag ensure there is a CHANGES/<num>.doc

If not present, fail the job.

Associated revisions

Revision 2f9fef53 View on GitHub
Added by daviddavis 7 months ago

First pass at checking for changelog entries

refs #4983 https://pulp.plan.io/issues/4983

History

#1 Updated by daviddavis 7 months ago

I have a PR that just checks for the file if it finds an issue in the commit. I didn't have time unfortunately to do all the requirements but I think this'll be a good stopgap until we do.

https://github.com/pulp/plugin_template/pull/89

#2 Updated by amacdona@redhat.com 7 months ago

I think the logic should be:
If it's a story ensure there is a CHANGES/<num>.feature OR CHANGES/<num>.misc
If it's an issue ensure there is a CHANGES/<num>.bugfix OR CHANGES/<num>.misc
If it has the documentation tag ensure there is a CHANGES/<num>.doc OR CHANGES/<num>.misc
If

This gives the devs the ability to decide that any particular issue should not be a line item in the changelog. Here are a few use cases:

1. A story is broken out into multiple stories. There is no reason to add more than one changelog line item if a feature is added and expanded in the same release. Example: add an endpoint, and then add a flag to that endpoint. This would be easier to consume for users as a single line item.

2. A bugfix for an unreleased feature should not have a changelog entry, because the users could never have experienced that issue.

3. A typo fix for documentation could be mentioned, but is overly verbose.

#3 Updated by daviddavis 7 months ago

@asmacdo that sounds fine to me with the exception of one problem: I see a significant number of tasks in redmine that impact users or plugin writers (here's a recent example[0]). I wonder if we should just validate that all changes to the codebase have CHANGES entries.

[0] https://pulp.plan.io/issues/5227

#4 Updated by amacdona@redhat.com 7 months ago

  • Status changed from NEW to MODIFIED
  • Assignee set to daviddavis
  • Sprint set to Sprint 57

After discussion on IRC, we decided that it would be best to ensure that there is an entry for every type redmine issue, but not to enforce that it is any particular type. This is already in place from the associated commit.

#5 Updated by bmbouter 3 months ago

  • Sprint/Milestone set to 3.0.0

#6 Updated by bmbouter 3 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF