> On Nov 10, 2022, at 10:34 PM, Richard Zowalla <r...@apache.org> wrote: > > Currently, it is not possible with Jenkins to run jobs from forked > repositories or for contributors, who do not have committer access to > the TomEE repositories.
Thanks for getting that confirmed. > However, they are discussing the possibility of having temporary nodes > (on k8s) in the future, so these (security) restrictions can be > dropped. > > Another possibility would be to explore the use of GitHub actions for > running or (quick) tests in a PR build. I remember, that we > experimented with it in the past and it wasn't a good option due to > limitations / timing / resources. Maybe time to revisit and try the > "quick" build for PRs / commits again? Speaking for myself only, I personally would not want to see PRs merged with only a quick build. I always do a quick build before pushing any code and I routinely break the build. Similarly, I don't like to merge PRs that do not have full clean build as I would feel it's my responsibility to find/fix any issues they caused. Library upgrades in particular more often than not break something in the build, so definitely need a full build before merging. > The workaround is to push the branch to the asf repo and let it build > (as we are doing it). Along these lines, we should be able to setup a manually run PR builder where we just enter the PR number and it does the rest. The git portions might have to be a shell script, but it should be a little better than having to make an entire job definition for one PR (and also having to delete those old job definitions later) I don't really have the time to work on anything like that now, but seems promising if someone wanted to volunteer. Theoretically, anyone with access to a jenkins install could try it out, get something that works and then we can set it up in the Apache install. -David
smime.p7s
Description: S/MIME cryptographic signature
