Editors Note: We created a webinar to show you all these new features with live demos for each. Scroll to the bottom of this article to watch the webinar!
When we add new features to the Codefresh platform we are always focusing on two major areas:
- Operator productivity especially when it comes to Docker/Kubernetes/Helm
- Developer productivity for applications that are designed with microservices
A big driving force behind new features is also the feedback we get from existing customers. Today we are launching a brand new pipeline creator and editor that is centered around the introduction of a “Project” as a top-level construct. Projects can be used to group pipelines in the same way that developers also use “Projects” for source organization.
The new Codefresh UI will be very familiar to developers or any other IT professional that has experience with Integrated Developer environments. All pipelines you create now belong to a single project. When you open a pipeline you can see all pipelines that belong to that project as well (shown on the left sidebar). The middle view is the pipeline editor (similar to a code editor) and the right sidebar contains pipeline settings such as triggers and variables (similar to settings or properties mini windows on IDEs).
You can create as many projects as you want and also mark them with tags for easy management and access control. You can start tagging your projects now, and we will soon integration projects in the existing security infrastructure (already present for clusters and pipelines)
Once your project is created, you can start creating pipelines directly on it or add existing pipelines to a new project. A project can be anything you want; you can use projects for any possible workflow as the definition of a project is not enforced by Codefresh. Some examples of Project ideas are:
- An application that is composed of micro-services
- A specific team of people
- A specific department
- A set of clusters based on location
There are also several settings that you can define on the project level. These include:
- Access control tags
- Top-level parameters
This gives you another way of centralizing configuration as common settings can be shared by pipelines that belong in the same project in addition to using shared configuration.
Notice that for new customers projects are already enabled as the default way of creating pipelines. Existing customers can work both with the new (Projects) and the old way (repositories) when creating pipelines.
Loading pipelines from another repository
Codefresh has always supported the capability to use a Codefresh pipeline from an external repository (other than the one that contains the source code).
With the new project view we also improved the UI that allows you to define exactly where the codefresh.yml definition is loaded:
You can now define explicitly which branch will be used for fetching the codefresh.yml file. You can also choose the Dynamic option if you want the branch to be the same as the one mentioned in the git webhook.
If for example your pipeline is triggered by a commit in the staging branch of the source code, the pipeline definition will also be loaded from the staging branch of the git repository that contains the codefresh.yml file.
For even more advanced examples of pipelines defined externally see our dedicated blog posts:
- Programmatic creation of Codefresh pipelines – part 1
- Programmatic creation of Codefresh pipelines – part 1
Git repositories are now mapped to projects
Before the introduction of projects, Codefresh was using a Git repository as the top level concept. Using the Git repository as a way to organize pipelines has worked well in the past, but we got feedback from customers that grouping pipelines under repositories can be restrictive, especially for applications that need multiple git repositories.
To help existing customers migrate to projects, both views (projects and repositories) are available in the Codefresh UI. They both work on the same underlying data so any changes you make to your pipelines on the repository view will also be reflected in the project view.
All existing repositories have also been migrated to projects. This means that you can start using projects right away. There is no need to create new projects for your repositories.
It is also possible to assign detached pipelines (i.e. those that are not linked to a repository in a project) from the pipeline view.
Notice, however, that any new pipelines you create from the project view will not be shown in repositories.
The git-clone step is now required
Because pipelines are not connected to any repository any more, the git-clone step is now required for a pipeline. In the past, pipelines that were connected to repositories were using an implicit clone step. Existing pipelines (in the repository view) will still use it, but all new pipelines must include an explicit clone step (if you wish to checkout code in the pipeline)
In the most simple case you can checkout a specific git repository (regardless of any triggers).
version: '1.0'
steps:
main_clone:
title: 'Cloning main repository...'
type: git-clone
repo: 'kostis-codefresh/allure-docs'
revision: master
PrintFileList:
title: 'Listing files'
image: alpine:latest
commands:
- 'ls -l'
However, if you want to take advantage of the new project concept, you should instead use an dynamic clone step that gets all information from the trigger of the pipeline.
version: '1.0'
steps:
main_clone:
title: 'Cloning main repository...'
type: git-clone
repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
revision: '${{CF_REVISION}}'
PrintFileList:
title: 'Listing files'
image: alpine:latest
commands:
- 'ls -l'
This pipeline will clone the repository that is mentioned in the git trigger. This allows you to create a single pipeline for multiple microservices (that are packaged in the same manner) and just different triggers for each microservice instead of adding different pipelines.
Notice that only brand new pipelines created in the projects view will need an explicit clone step. Existing pipelines will still work as before. No changes are needed there.
Triggers can now be disabled
One of the most requested features was the ability to enable/disable triggers on demand. Until recently the only way to do that was to delete the trigger and recreate it.
We have listened to what you are asking and in the new projects view, the triggers also show a toggle button. Just click on it and Codefresh will ignore that trigger completely. You can toggle it again when you want to re-enable that trigger.
How to migrate from repositories to projects
First of all there is no rush to do anything. All existing pipelines are working as before. The repository view is still there and fully usable. At the most extreme scenario you can simply disregard the new projects view and still keep working as before (of course you lose all the new features as well, such at the ability to load pipeline definitions from private repositories).
All your existing repositories are fully migrated to projects and you can start working with them right away. For backwards compatibility all your existing pipelines that did not have any trigger at all, have now gained a new trigger to mimic the old behavior (where a pipeline was linked with a repository). This trigger is disabled by default and it does NOT affect your existing pipelines. Feel free to enable it if you need it. If you already had triggers in all your pipelines, nothing has changed.
You will also see a warning for git clone steps, reminding you that they are now required. Any pipeline however that shows the warning will still work as expected. There is no immediate action needed on your part.
In summary, you can take your time with migration. The repositories view will be available for the close future (some months), so you have time to explore the new features and plan your own migration period. A natural migration path is to create all new pipelines in the projects view, while still leaving the old ones in the repository view.
Pipeline editor improvements
Even though a pipeline definition (codefresh.yml) should be ideally fetched from source control, Codefresh also comes with a built-in pipeline editor that allows you to edit and run a pipeline on the spot. We have been continuously improving our editor for easier debugging and more friendly error checking.
The editor now offers a “formatting” view that helps you identify line breaks, spaces, and tabs. This makes it very easy to solve common yaml formatting errors which have been plaguing any editor that has to deal with YAML content.
This is just one of the first iterations for making the editor more powerful. We are working on several other features that will make pipeline editing as easy as possible.
Ready to try Codefresh, the CI/CD platform for Docker/Kubernetes/Helm? Create Your Free Account Today!