Creating effective Continuous Integration pipelines is a daunting task that requires combining knowledge from different areas. At Codefresh we have always strived for a fast feedback loop between both customers and prospects in regards to pipeline speed and simplicity. We always want to improve the onboarding process for everybody regardless of their position in the cloud native journey.
Today, we are releasing 3 important features that can help you simplify your pipelines and make them more secure.
The first addition is the ability to make shallow git clones. This means that the pipeline can only checkout the current state of a Git repository without all its history. This will make your pipeline a lot faster. For big repositories with a long history, the speed gains will be especially important.
The second new feature is the ability to decide which Kubernetes clusters will be usable/visible from a specific pipeline. This can make your pipelines more secure as you can lock them only on the Kubernetes clusters that they really need. For example, you can allow only QA pipelines to touch QA clusters, prod pipelines to see only prod clusters and so on.
The third feature is the ability to skip automatically all builds if [skip ci] appears in the commit message of a git trigger. This conserves resources and results in fewer builds in cases where you change something in the source code that doesn’t need a full build (e.g. spelling mistakes in the README file)
Let’s see them in order.
Faster pipelines with shallow clones
By default any git clone step fetches the whole Git repository including all history. This can help developers examine different branches and check history logs in an easy way, as all information is stored locally. But in the context of CI pipelines this amount of information is not always needed. Almost always a pipeline works with a single branch and in most cases we are only interested in the latest code commit only.
Git offers several options for fetching part of the repository (in the form of sparse indexes and sparse checkouts). The most straightforward way to focus on the last commit and nothing else is the depth option. This allows you to fetch any specific number of past commits or just work on the latest one.
Codefresh pipelines could always employ the depth option using a custom clone step. Today we are simplifying shallow clones by incorporating the depth parameter in the native Codefresh clone step.
You can now change the yaml of the pipeline to
version: '1.0'
steps:
main_clone:
title: 'Cloning main repository...'
type: git-clone
repo: 'my-user/my-repo'
revision: 'master'
depth: 1
You can choose any value for depth similar to the Git CLI option.
If you have very old Git repositories with a long history that also includes binaries, the depth option can offer a significant performance boost to your pipeline.
Notice however that you need to make sure that the pipeline doesn’t do anything with git history or other branches or other commits. We advise you to enable this option gradually in your pipelines to minimize disruptions.
Choosing which clusters will be accessed by a pipeline
One of the main advantages of Codefresh over traditional VM based solutions is the tight integration with Kubernetes clusters. You can define your Kubernetes clusters once in the integration screen and then access them by name in your pipeline.
In the example above, I have connected 2 AWS clusters in my Codefresh account. Now in any pipeline I can deploy by using their names (e.g. aws-eu) without bothering with manual kubectl commands or handling complex kube-config setups
This pattern can help you a lot for simplifying pipelines because each developer can now create a deployment pipeline without having any credentials to Kubernetes clusters.
However, depending on the size of your organization you might have a large number of Kubernetes clusters and you might want to further subdivide which pipelines have access to which clusters.
You can now choose exactly which clusters you want to be accessible from each pipeline in the policy screen of that pipeline. This not only makes the pipeline more secure but also helps developers avoid confusion with clusters that might have similar names.
This has been a very popular feature request from existing customers and we are really excited that it is finally available for better organizing your pipelines and clusters
Skipping a CI build according to the commit message
Last but not least we have also implemented another popular feature for the sake of compatibility with other CI systems.
Codefresh will now automatically parse the commit message from Git triggers and if it contains phrases such as [skip ci] or [ci skip] (and other variations) the build would be completely skipped.
This was previously possible with a custom pipeline step, but now it becomes far easier for users to take advantage of this feature as it matches their expectations with migrating from another CI system.
You can use this feature to speed up your builds. For example, if a pipeline compiles a large software project, and you only update the README file, you can add the [skip ci] words in the commit message and no compiling will take place.
Looking ahead
These features have been part of a huge internal effort to invest more in the Codefresh CI product in preparation for the merge with the GitOps product. Even though the CD and GitOps product can be used with any CI solutions, we always want to make Codefresh CI the natural choice in order to get access to a full and cohesive platform for the full software lifecycle.
Get started today by creating an account and we would love to hear from you!