You could potentially use a build strategy to only build PRs that contain one or more labels on the PR, and labels can only be added by committers by default. I've used this plugin at work recently for building an opt-in acceptance test pipeline: https://plugins.jenkins.io/github-label-filter/
On Fri, 14 Aug 2020 at 18:25, Chris Lambertus <c...@apache.org> wrote: > > > > > On Aug 14, 2020, at 4:01 PM, Richard Eckart de Castilho <r...@apache.org> > > wrote: > > > > Hi, > > > >> On 30. Jul 2020, at 05:42, Chris Lambertus <c...@apache.org> wrote: > >> > >> There is no policy per-se, we have done this in the past, specifically for > >> repo:status tokens; > >> > >> Please create an infra jira ticket. Unfortunately, it’s an extremely > >> manual process on our end, and requires Infra to create and maintain an > >> account and password+token for each project, so it’s something we try to > >> avoid unless absolutely necessary. > > > > In which case would such a thing ever be "absolutely necessary"? > > If your project can justify the extreme need of an additional token because > your project has so many build requests that exceed the rate limits of the > asf-ci token Infra already provides, we'll evaluate it. We would prefer you > discuss the needs of your build with Infra so we can assess and allocate > resources as appropriate. > > > > > > However, I have come to find it very very convenient to be able to visit a > > PR and see how it fares, in particular since I like setting up repos to not > > permit merges unless the CI gives its thumbs up - which is of course also > > not absolutely necessary - but useful. > > > > Is there any chance there might be a more generic solution than using > > personal tokens or high-effort investment of INFRA to the problem of > > setting the commit status on GitHub from ci-builds in the near future? > > > > Cheers, > > > > -- Richard > -- Matt Sicker <boa...@gmail.com>
