>
>
>
> The ASF does not run Travis. We pay a large amount of money TO Travis for
> additional workers on top of the free tier. The reason I ask for discussion
> regarding Jenkins usability is because throwing infinite money at solutions
> like Travis is not an option. Now you find yourself in the
>
>
>
> I presume you are referring to the fact that external non-committers
> cannot force a build on a forked repo PR on the ASF Jenkins without
> whitelisting [1]. This is by design because it is a huge security problem
> to run unvetted 3rd party code on our build infrastructure. This is the
>
>
> >
> > The multiple threads about how shitty those are in practice for your
> > needs seem to indicate otherwise. Security and easy learning curves
> > don't seem to get along too well, do they?
>
The usabilty, integration level (especially GitHub Actions), maintenance
effort needed
- thi is fa
Le 09/01/2021 à 12:01, Jarek Potiuk a écrit :
>
> So if only we had 'approved', "secure" and easy way of running our own
> self-hosted runners + a way from Github to distribute the free resources in
> a fair way among the project. - the problem would be immediately solved.
> This is really what
And BTW. The change we (Ash) proposed in November is very, very reasonable
one.
It does not require GitHub to change any of the architecture for security,
nor any of the components besides
runner configuration.
I will quote Ash here as I would not be able to put it better. Antoine,
please
take a l
I work on the Jenkins security team. We don’t have embarrassing security
failures like this anymore, but part of that is due to the added complexity
of a secure configuration. By the time GA meets your security standards,
it’ll likely either require non-trivial changes to your CI scripts, or
it’ll
