checkstyle / contribution

If an issue cannot be found,

contribution/releasenotes-builder/src/main/java/com/github/checkstyle/github/NotesBuilder.java

Line 147 in 21ad136

final GHIssue issue = remoteRepo.getIssue(issueNo);

releasenotes-builder will throw a GHFileNotFoundException and will kill the execution.

If this occurs it will be unable to process release notes. Since you cannot remove commits from Git at the time we get to this point, release note generation will be unable to continue and we would have to switch to manual creation. No output or such is created before this exception.

Even if we build safe guards into PRs and such to prevent this, Admins have direct push access and our commits are skipped by validation.

We should find an appropriate way to handle this in the utility if it ever occurs.

we never had this problem , because CI validate referenced issue.
It is ok for tool to fail with exception, at least exception will be clear and maintainer will be able to understand what to do.

If this problems occurring:
We should print WARN, and treat this issue as "miscellaneous".

Yes, as long as CI runs on Issue'd commits, it will be flagged. This, however, makes it the job of the PR merger to verify that this specific CI runs. We have had weird issues with CI all the time.

Just to be clear, maintainer will not be able to do anything with the releasenotes-builder as said above. It will stop processing in it's track.

If CI is in bad state, do not release.
We always extra careful at such time.

In worse case we will have bad number of release it is not end of the world.

@romani Should this issue be closed?

As a reminder, if this ever happens, release notes will not be able to be generated and we will either have to forgo release notes for a release or do them manually by hand and possibly be error prone.

if it happens we will have red status on

if this is not good sign for person who is going to make release, it will fail in the middle of release process and it will block it.
Unpleasant situation but it will teach to look at CI before release.

Do you suggest to make it as WARN and skip it ?
to not actually block everything, and is maintainers does not care , it meant it it ok to not reference in release notes.
or should be make put it as-as in miscellaneous group (no reference/link to issue/PR).

message below is taken from https://checkstyle.org/releasenotes.html#Release_10.5.0
if there is valid issue/PR we do:
Issue #11604: separates detail ast from xpath. Author: rnveach [#11617](https://github.com/checkstyle/checkstyle/issues/11617)
if reference is invalid we will do (just handy link is dropped, commit message is copied as-is):
Issue #11604: separates detail ast from xpath. Author: rnveach

I believe you have said that the release should still go even if CI is failing all over the place.

We should keep this as error so CI continues to fail on it in PRs. I think we should instead have a skip property for release notes that it skips all errors and continues on as best as it can to not fail. Like you said, for this issue it can use commit message. Everything that was an error before can be converted to a warn with the skip on. We will only use this property as a last resort for release process. I am ok with putting it as miscellaneous and we can have a note to ourselves to move it if we disagree as we are manually handling release notes at this stage.

we probably can not fail there, as if for some weird case wrong reference passed in master(for example CI are deactivated or failed to notify us on failure) we can not fix it, we do not allow to change git history in master. So what is merged is set in stone.
We can not change commit and we can not change ids in Github.

All we can do is just put this update to "Notes" section of release notes. We do not need extra property.

I was not saying to change git history. Property is just to turn error into warn so we can continue on if we have gotten to that case.

releasenotes does not work in PR.
it works only on master, so no reason to have.

Please confirm that it is ok.

I don't think it should be enabled all the time so its always a warn, but if thats what you want.

I see no reason to do behavior customizable. It would not in use in our current usage. If something change in usage, we can always update code.

Resolution: we should do Warn and make default section "Notes" for all not found from GitHub.

Fix is merged

releasenotes-builder: Exception on unknown Issue