AWS Codepipeline with multiple source and build actions

user_7605455 0
Viewed 818

i am creating a codepipeline for a microservice based application. i want to utilize one single pipeline and codebuild project for this CICD. I have a specific case where i am using more then two actions in source stage. every action gets code from different github repo and generate different output artifacts. then in next stage i have created multiple build action which takes input artifacts from respected output artifacts of mapped source action. the problem i am facing is that code change in one of repo triggers every action to start full pipeline that results in new deployment of every microservice. i am using terraform for creating all this.

enter image description here

when code changes in Source-dmthen only source-dm of Source Stage and DM-Build should run and deployment just happens only in DM microservice. please help me getting a swift fix. thanks in advance.

multibranch-pipeline aws-codebuild terraform aws-codepipeline
1 Answers

I don't believe that you can pull this out with a single CodePipeline, at least you can't do it natively.

In general, you either have PollForSourceChanges or webhook enabled or you don't. As you are using Github Version 2 Connection as far I can see from the screenshot, changes in either of the repos will trigger your pipeline as you describe.

I can think of a few options which could solve your issue and from which you can choose based on your use case.

  1. The obvious one would be to have one pipeline per repo (one for dm and one for sampling - in that case whenever there is a change in one of them you'll just build and deploy to the respective microservice (you'll need to absorb the cost of 1$ for one additional pipeline in that region)
  2. You can produce a hash of the build on the second step and then add a check prior the deployment to see whether the checksums are matching and if they are do not deploy the new build for this service.
  3. You can potentially add a check in the buildspec of the build to see whether the commit id from the current execution matches the previous one and if that's the case silently ignore it and don't produce a build. Then have another check in the one with which you deploy the microservice to see whether there is a new build and in case the answer is no, do not deploy.
  4. You can still use this pipeline for the builds, but then cascade it to another one (or another job for the deployment process). In that job (could be a lambda) you can check whether the commit id from each repo matches the commit version from the previous exectuon and then only deploy to the one that was actually changed.

If it was me, and in case there is some context that we are missing, as you havent mentioned it, the best possible approach is Option 1, just create two separate pipelines, as the other options are adding unneeded complexity.

user_94056020
Related