Project

Profile

Help

Task #4983

closed

Add changelog check to the Travis configuration tool

Added by bmbouter almost 5 years ago. Updated over 4 years ago.

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

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Plugin Template
Sprint:
Sprint 57
Quarter:

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.

Added by daviddavis over 4 years ago

Revision 2f9fef53 | View on GitHub

First pass at checking for changelog entries

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

Actions #1

Updated by daviddavis over 4 years 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

Actions #2

Updated by amacdona@redhat.com over 4 years 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.

Actions #3

Updated by daviddavis over 4 years 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

Actions #4

Updated by amacdona@redhat.com over 4 years 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.

Actions #5

Updated by bmbouter over 4 years ago

  • Sprint/Milestone set to 3.0.0
Actions #6

Updated by bmbouter over 4 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF