[ 
https://issues.apache.org/jira/browse/BEAM-8548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965516#comment-16965516
 ] 

Lukasz Gajowy commented on BEAM-8548:
-------------------------------------

CC: [~kamilwu]

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

Reply via email to