That is correct. All jenkins job changes will need to be serialized so active communication in Slack would be a good way for people to know that they are running the seed job.
On Thu, Mar 29, 2018 at 9:54 AM Robert Bradshaw <rober...@google.com> wrote: > On Thu, Mar 29, 2018 at 9:45 AM Lukasz Cwik <lc...@google.com> wrote: > >> >> On Thu, Mar 29, 2018 at 5:20 AM Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >> >>> Hi Reuven, a few questions: >>> >>> 1. any inputs on how we can work on the jenkins part? Do we test it live >>> wiht "fake" PRs? >>> >> >> The jenkins jobs are configured via this seed job ( >> https://github.com/apache/beam/blob/master/.test-infra/jenkins/job_00_seed.groovy) >> which >> seeds all of the jobs found here ( >> https://github.com/apache/beam/tree/master/.test-infra/jenkins) >> On a PR which modifies a Jenkins job configuration, you need to manually >> run the seed job with the github PR trigger 'Run Seed Job' and then you can >> launch your modified version of the job with its github PR trigger. >> > > We'll probably need to have some mechanism to ensure people don't stomp > over each other doing this. (Right now I suppose we rely on the infrequency > of such commits.) > > >> 2. What's the rational to not start by deleting the poms? Sounds like it >>> will be a day working on gradle and on the 4th we'll be back on maven >>> >> >> I would be for disabling the jenkins pre-commits/post-commits that are >> maven based and only keep around gradle enabled ones (so our Jenkins >> cluster doesn't get overloaded). >> >> Also, keeping the pom.xml allows you to compare your Gradle build against >> the Maven one from the same workspace to make sure that they are >> equivalent. If we deleted the poms, people hacking would need to use two >> different workspaces. I'm not sure which would be easier for people working >> on the hackathon. >> >> >> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> 2018-03-29 4:46 GMT+02:00 Reuven Lax <re...@google.com>: >>> >>>> Hi all, >>>> >>>> Last week we discussed having a "fixit" day for Gradle, and I >>>> volunteered to organize it. A number of people volunteered to help, from >>>> multiple organization. I'd like to say that it's great to see such a >>>> diverse set of people volunteering to help here - this is a great way to >>>> build community! Everyone who explicitly volunteered is directly cced on >>>> this email, though we'd love for more of the community to help. >>>> >>>> The agreed upon date is April 3. The top-level JIRA tracking this work >>>> is >>>> >>>> ttps://issues.apache.org/jira/browse/BEAM-3249 >>>> <https://issues.apache.org/jira/browse/BEAM-3249>, and we currently >>>> have 26 subtasks linked to it. I've created a Kanban board to track these >>>> issues, which I'll share out soon. We will use Slack the day of the fixit >>>> for collaboration and for questions. >>>> >>>> >>>> Two major goals for this fixit should be to 1. Remove Maven runs from >>>> our Jenkins executors and 2. to migrate our release process fully over to >>>> Gradle. A lot of work has already been done on 1., and we've made some >>>> progress on 2.. Slightly longer-term the goal is to delete all of the pom >>>> files; I'm not sure we'll get as far as completely deleting Maven in one >>>> day, but we should get within striking distance! >>>> >>>> >>>> Thanks in advance to everyone who's helping out! >>>> >>>> >>>> Reuven >>>> >>> >>>
