A shallow clone would not be sufficient as it would not capture the history of changes back to the previous release. It meant cloning a potentially large and growing repository at the start of the build. The first option was one I wanted to avoid.
GIT CHECKOUT TAG WITHOUT CLONE FULL
Clone the full repository manually in a CodeBuild step.I looked at two options to find out folders which had seen changes since the last successful deployment: This is a technique described well in this Shippable blog post.
I wanted to run these kind of checks to determine which microservices in our monorepo had changed so I knew which ones to build and redeploy. Some CI environments will give you a "shallow clone" without the full Git history, leaving you with a similar challenge.
This makes it impossible to run checks on what has changed since a previous build or even to determine what has changed in the commit that triggered your build. Instead of giving you access to a cloned repo, AWS CodeDeploy gives you a snapshot of your code without the. Other tools, and I am talking specifically about AWS CodeDeploy, take a different approach. When I used Jenkins, Travis or Circle CI, I had access to the cloned Git repository and could use git log, git ls-remote and git diff without any problem. This will usually be in your automated build environment.
There are some cases where you want to find out information about changes in your Git repository without having to clone the full repository.
0 kommentar(er)
