[ 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)