Hello devs,
while migrating some jobs from travis to github CI, I started making
some (time consuming) jobs and/or build steps conditional based on PR
labels.
I keep it here short since most of the info is in the PR text, but as
example:
The new test job called "Build Tools" would only run if the PR is
labeled with Ant, Gradle, Maven or MX.
There are also additional command labels available, ci:all-tests would
enable everything, while ci:no-build would as you would guess disable
everything (e.g if all what the PR does is to edit a readme or sync-PRs
which syncs two branches could use this too, since they build everything
twice right now).
This is just about PRs, the merge will always test everything on master.
Why labels and not path based dependency checks? Because they never work
outside of fairly trivial cases in my experience. They either test too
much or not enough and whats worse: the dev has to second guess if the
right things are actually being tested - if they aren't there must be
also a second mechanism to override the automation.
With labels, reviewers can decide what needs to be tested based on
experience. A correctly labeled PR should "just work" most of the time
even if you wouldn't know about the details. However, everyone still has
to know about it: If you want the right things to be tested, you have to
label the PR _before_ pressing the create button, otherwise the first
run will have the wrong settings. (syncs will pick up new labels)
I was considering to fail the build for PRs without labels (not
implemented).
https://github.com/apache/netbeans/pull/4431
feedback appreciated,
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
