Page History

...

• is the PR labeled?
• did the right tests run? When did they run?
• is the commit msg and author information (mail, name) correct/descriptive?
• does the PR title and text still fit to the PR after the Nth iteration?
• does a refactoring/cleanup obfuscate a bug fix? (suggest to split them into separate commits)
• (... the obvious things: does this PR improve the project? Is it correct, maintainable, properly squashed etc)

PR merge check list

• same as above
• if the PR targets the delivery branch: don't merge, see PRs for delivery
• am I willing to accept this side quest? If yes → merge

PR triggered CI Jobs (conditional CI pipeline)

...

• All labels which influence CI contain the [ci] tag in their description which is there to make it easier to find them:
  https://github.com/apache/netbeans/labels?q=%5Bci%5D
  Image Added 
• The description mentions what steps or jobs the concrete label is enabling. See link above for examples.
  Image Added

This system is designed to be intuitive and uses basic category labels which were already in use before the conditional CI pipeline was implemented. A PR which improves maven features should have the Maven label on it. The fact that this label is also enabling additional maven tests is just an implementation detail. In most cases it should "just work" without having to think about it.

...

• labels are read by the workflow the moment the workflow is triggered. This is why it is important to label a PR before the create button is pressed, otherwise the first workflow run will use the wrong settings
• non-committers can't label PRs, reviewers must do that for them, the next PR sync will take new labels into account (90% of all PRs need syncs anyway after review)
• if a PR doesn't have to be synced anymore, a fresh workflow run can be forced via a hidden trigger: Lock the Conversation and unlock it again and it should start on the unlock event.
• workflow runs by non-committers have to be approved before they run, unfortunately the labels are read at the moment the workflow was created, not when the "approve and run" button is pressed.

Labels are also

...

used to generate the Release Notes

Another reason ALL PRs should be labeled before merge - check before approval please.

...

Individual failed jobs can be restarted as long as the pipeline artifact didn't expire (currently set to 2 days). Once it expired or the workflow was manually canceled the whole workflow has to be restarted from scratch, since only the primary build jobs which run at the start of the pipeline create the artifact.

Image Added

Image Added

see https://github.com/apache/netbeans/actions or "Checks" section below the PR to access the workflow run.

Unreliable tests

Unreliable tests can be wrapped in a retry script, a retry will add an annotation to the workflow summary page, for example:

Image Added

Tips/Tricks

Github GitHub can generate diff or patch files for you directly from PRs. All you have to do is to add append .diff or .patch to the PR url.

Patch files are also useful to quickly check commit headers (emails, names etc) from new contributors but also a time saver for big PRs (grep or diff with NetBeans).

...