[
https://issues.apache.org/jira/browse/BEAM-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamil Wasilewski updated BEAM-8548:
-----------------------------------
Status: Open (was: Triage Needed)
> Provide separate Jenkins job instances for each triggering modes
> ----------------------------------------------------------------
>
> Key: BEAM-8548
> URL: https://issues.apache.org/jira/browse/BEAM-8548
> Project: Beam
> Issue Type: Improvement
> Components: testing
> Reporter: Lukasz Gajowy
> Priority: Minor
>
> Currently, there are several Jenkins job definitions that can be run in
> multiple ways (excluding manual job invocation from jenkins dashboard):
> - periodic invoaction (cron)
> - pre/post-commit
> - phrase triggered invocation (on demand)
> I'd suggest we separate the single job that can be triggered many ways to
> multiple job instances that can be triggered one way only. For an IOIT this
> would look like this (example):
> -
> [beam_PerformanceTests_MongoDBIO_IT|https://builds.apache.org/view/A-D/view/Beam/view/PerformanceTests/job/beam_PerformanceTests_MongoDBIO_IT/]
> (for the "cron" job version)
> - beam_PerformanceTest_MongoDBIO_IT_PR (the phrase triggered version)
>
> *Why even do that?*
> This approach brings much more elasticity in terms of job configuration. For
> example:
> - we can stop sending emails to builds@ for jobs that are Phrase triggered
> - phrase triggering is signalled on github so there's no need for an email.
> builds@ could in turn be notified only for important reasons
> (preCommit/postCommit fails, cron job fails). This was discussed in BEAM-8422.
> - we can store metrics collected during testing in different db tables/not
> store them at all so that the results from master/Pr branches do not mix up.
> Ideally, when we look at the IOITs chart, we'd like to skip the results from
> a Phrase trigged job invocations and stick only to data collected from master
> branch (cron jobs versions would do that). This was also discussed in
> BEAM-6011
> Some of the jobs already follow this approach, at least partially. Part of
> task would be to ensure that we are consistent in naming and conventions that
> we follow (_cron, _Pr/_phrase suffixes in the job names, more?). It would be
> best to enforce the conventions programmatically using job builders and
> proper API written over groovy job dsl. This is so that it's impossible to
> break the conventions when adding new jobs.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
