I took a peek and the seed job seemed a bit different than the test jobs
that use PostCommitJobBuilder to construct their normal & _PR variants. I
didn't see how to appropriately plug in the helper code after 5 minutes of
reading. But I am probably just a bit unfamiliar with the refactoring and
Yes, the SeedJob is not ideal because it's the only way to test Jenkins job
changes, but there's no easy way to sandbox your testing-- running the seed
job regenerates all live jobs from your PR.
Splitting the SeedJob like we have for others based on trigger (cron vs
phrase) would be an easy
Ah good point. That's why we were frequently seeing these mails. Would
be nice to be able to test Jenkins DSL changes without generating an
email to a mailing list.
On 22.10.18 17:25, Kenneth Knowles wrote:
Another thing about the seed job: for jobs like 'Java Postcommit" there
is a separate
Another thing about the seed job: for jobs like 'Java Postcommit" there is
a separate job for whether it is run as an actual postcommit or whether it
is run against a PR. The seed job has not been split this way. So when
someone is testing the seed job on a PR failures look the same as if it is
Hi Rui,
The seed job being broken is sort of a big deal because it prevents
updates to our Jenkins jobs. However, it doesn't stop the existing test
configurations from running. I haven't found the mails annoying but I'm
ok with moving them to the builds@ list.
-Max
On 22.10.18 11:05, Colm
We had a discussion recently about splitting the JIRA notifications to a
new list "issues@b.a.o", and also splitting the Jenkins mails to
(potentially) "builds@b.a.o". So I guess the issue you raised can be done
once the latter mailing list is set up and active.
Colm.
On Fri, Oct 19, 2018 at
Hi Community,
I have seen some Jenkins build failure/back-to-normal emails in dev@ in
last several months. Seems to me that this setting is coded in
https://github.com/apache/beam/blob/master/.test-infra/jenkins/job_00_seed.groovy#L100
.
In the link above, the comment says the seed job is very
