[
https://issues.apache.org/jira/browse/BEAM-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Gajowy updated BEAM-8548:
--------------------------------
Description:
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.
was:
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.
> 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)
