FEOLMIS-2826

This looks good Jakub Kondrat. Any new updates?

I did followup on the Transifex reasoning and while we might have an issue for follow-on work when we do want to build any branch at any time, I think for now there's no issue here so long as our development process keeps to trunk based development.

Next thing: Thanks for adding in the stages to run contract tests. It's exactly what I asked for, and the more I've had a chance to think about it, I think it may not help the team as we copy this pattern to the other services. It got us the general picture: we don't want to sign-off on a build if the contract tests don't pass. It however does so very verbosely by directly checking out the contract tests and running them.

Instead I think you we're right initially, we'd prefer to invoke the contract test remotely. What we wouldn't want to do though is pass the pipeline if the contract test fails, so we need to invoke the contract tests from within the pipeline. Ideally that would mean calling one parameterized jenkins job with a parameter that let contract tests know which service changed and it would determine which tests to run. That might be too much to change all at once though, so lets call the contract test jobs as they are today from within the pipeline, and wait for each job to pass/fail before we pass/fail the pipeline. This looks helpful: https://stackoverflow.com/questions/43337070/how-to-invoke-a-jenkins-pipeline-a-in-another-jenkins-pipeline-b/43340921

Josh Zamor: It's good to hear that Transifex is not an issue now.
I made the pipeline invoke existing jobs in order to run contract tests. The downside is that the pipeline job will still occupy a build slot while waiting for these tests to complete. I parallelized contract test and sonar analysis stage, so it shouldn't be a big issue as long as we have more than one executor slot.
Other than that - no updates. Is there anything else that needs to be done? Here's a ticket for creating that parametrized job: OLMIS-4625

Thanks Jakub Kondrat, a few more things to note:

• I think we forgot the build ERD step? And we'll need to archive it.
• Also I think as-is we don't have a Slack notification if the some of the stages fail. e.g. the Sonar stage fails? Is it possible to do this for the overall pipepline rather than each stage?
• Is it possible to archive the contract test results? I'm just curious it's not needed.

Some other nice to haves:

• Can we add log-rotate into the Jenkinsfile so that we only keep the last 15 or so builds?
• Can we discard branch builds after they're no longer relevant? Like this one: http://build.openlmis.org/job/OpenLMIS-referencedata-pipeline/job/OLMIS-2245/

Josh Zamor:

• I have added the ERD generation step
• We should now be getting a Slack notification if the whole pipeline fails
• I don't think it's possible to archive contract test results if we have them in a separate job
• Added build rotation (15 builds)
• Maybe discarding branch builds after x days would make sense? buildDiscarder(logRotator(daysToKeepStr: env.BRANCH_NAME == 'master' ? '' : '7'))

Update: After adding this Jenkinsfile to a couple other services, it turned out that a deadlock is possible - when the pipelines occupy all the available build slots (3), the external job for contract tests cannot be launched. I have installed this plugin https://wiki.jenkins.io/display/JENKINS/Throttle+Concurrent+Builds+Plugin
and added a "pipeline" group that allows only one job from this group to run on a node (so the second slot on slave will always be available for other jobs). This group can be configured under "Throttle Concurrent Builds" section in Jenkin's system configuration

Since there are no unresolved issues or questions, I'm going to close this review