On 12.08.22 15:25, Eric Bresie wrote:
Did I read correctly, it doesn’t run if there are no labels? What about
new contributors without permissions to label yet for a given PR?
reviewers. PRs of new contributors won't get merged on first attempt
anyway, its an iterative process.
CI doesn't run for first time contributors and has to be unlocked by
committers for security/resource abuse reasons, this is already the case
today.
An unlabeled PR from a contributor would start CI but with many long
jobs/steps disabled. It was just a suggestion that maybe we should fail
the build job early if a PR is not labeled - this is not implemented.
If the GitHub/travis practices are already documented somewhere then can
they be updated (once accepted) to have a centralized place for knowledge
of this (and the available labels)?
its documented in the yaml file, I am also planning to put a note on the
label description itself if it influences the build (using the colors
differently might be also an option).
https://github.com/apache/netbeans/pull/4431#discussion_r942356174
reviewers/project managers should take a look at this section. (I am esp
not sure about the JavaDoc label, since nobody gonna use it intuitively,
its still useful since javadoc is a fairly long step, we could add more
triggers for it, e.g "API Change" etc)
But in general: If this works correctly, you won't have to know about
it. All you have to do is to label the PR, it should "just work" since
the labels are not obscure flags. If your PR changes gradle, add
"Gradle", if your PR changes PHP, add "PHP". You should be doing this
anyway as committer and good github citizen so that reviewers don't have
to fix your PRs.
Reviewers should know about it though, since project wide cleanups would
for example require a ci:all-tests run before merge etc.
If they are not then is it worth starting to so folks have a centralized
place instead of searching through PRs or emails? Maybe somewhere near
here (1)? Or maybe a new page for GitHub similar to page for Jenkins (2)
with GitHub and GitHub Actions and practices documented?
having duplicated doc is dangerous and annoying (nobody wants to sync
docs if the impl changes), if you want it in a wiki, i would recommend
simply linking to the section in the yaml on github, maybe there is a
way to embed it.
best regards,
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
