pkg/oc/cli/admin/release: Issues from non-first-parent commits

[wking]

Sometimes a single pull request will address multiple issues, and listing them all in a PR subject is not feasible. With this commit, I iterate over all commits in the given range (merge or not), but only return a slice for the first-parent chain (which in most cases will be a series of merges to master). For commits that are part of the retrieved graph but which lie outside the first-parent chain, I find the nearest first-parent ancestor and attach any referenced issues to that ancestor. The new issue structure sets the stage for future work to also support references to GitHub and other issue stores, although I haven't added extractors for those yet (I'm planning on using git interpret-trailers).

CC @smarterclayton, @mfojtik, @soltysh, since this is following up on #22030.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: wking
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: soltysh

If they are not already assigned, you can assign the PR to them by writing /assign @soltysh in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/oc/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[wking]

Rebased around #22163 with 1c9eba8 -> cd8325b.

[wking]

verify:

2019/02/28 02:21:57 Inspecting imports under github.com/openshift/origin/pkg/oc...
2019/02/28 02:21:59 -- validating imports for 129 packages in the tree
2019/02/28 02:21:59 -- found forbidden imports for github.com/openshift/origin/pkg/oc/cli/admin/release:
2019/02/28 02:21:59 	vendor/github.com/pkg/errors

I was not expecting that :p. Anyhow, dropped back to the stdlib's errors package with cd8325b -> 59e763e.

[smarterclayton]

/hold

This is more of a discussion about how we want to do changelogs. We have very specific requirements in our release system around bugs and their linkage to code. In general, changelog doesn't exist to satisfy arbitrary git styles, but to satisfy the specific style we will use to fill out release advisories.

It isn't about displaying commit messages or even PRs (PRs are tolerated for now). It's about displaying bug fixes. So if we were to do something along supporting multiple we would do it for Bug X,Y,Z: (or at least, that would be the direction to start.

[wking]

It isn't about displaying commit messages or even PRs (PRs are tolerated for now). It's about displaying bug fixes. So if we were to do something along supporting multiple we would do it for Bug X,Y,Z: (or at least, that would be the direction to start.

I think only extracting these from our pull-request titles is going to make for unnecessarily-long pull-request titles. I want to write pull-request titles aimed at the repo's maintainers, for whom the link into Bugzilla is probably not top-billing information. With this commit, I can add the Bug ... prefix to my commit message subjects (where I might have a series of commits addressing each bug), and then I can put whatever I want in my PR title, and the scraper code here will still pick up the references. Folks who want to can also continue stuffing all the references into the PR title.

[soltysh]

I agree with Trevor here, I prefer a series of commits, each fixing one bug as the best possible approach. Commits better reflect history than PRs, I frequently filter out merge commits.

[ironcladlou]

FWIW, I think sometimes even a single commit scoped as narrowly as possible can fix more than one bug. I think assuming a commit per bug is too rigid.

[wking]

So if we were to do something along supporting multiple we would do it for Bug X,Y,Z: (or at least, that would be the direction to start.

I've filed #22225 for this.

FWIW, I think sometimes even a single commit scoped as narrowly as possible can fix more than one bug. I think assuming a commit per bug is too rigid.

Nothing assumes a commit per bug. This PR just allows a commit per bug to be documented via the individual commit subjects instead of rolled up in the PR title (although you can still roll up in the PR title if you want). And with #22186 and/or #22225 and this PR, we'd also allow each of those commits to address multiple bugs. Personally, I'm in favor of landing all three PRs.

[openshift-ci-robot]

@wking: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.