Projects require git clone steps
Migrating from implicit to explicit git clone steps
On May 2019, Codefresh introduced Projects as a way to group pipelines, instead of using Repositories. If you create a Codefresh account after this date, then you only get access to Projects and all the pipelines you create are under projects.
If however, you have an existing Codefresh account, you will still get access to both dashboards (Projects and repositories) and you can work create/edit pipelines using both methods.
Git steps are now required
If you visit any existing pipeline you will see a warning message about git-clone steps.
First of all we need to make clear that your pipeline will still work as before, without any changes. The migration to projects is a gradual one and Codefresh does not force you to do anything in order to make things work.
The warning message explains how new pipelines need a git-clone step. Codefresh pipelines based on repositories automatically cloned the source code for you.
This means that the repository based pipelines used to check out the code automatically, and all subsequent pipeline steps could start work with it right away.
codefresh.yml (old syntax)
For new pipelines this is no longer true. You need to add an explicit clone step. The step should be named
Here is the same pipeline in a project. The only thing you need to do is to add the
main_clone segment before other steps:
codefresh.yml (new syntax)
The values for
CF_REVISION will automatically be filled by Codefresh according to the trigger the pipeline has. Make sure to replace the
my-git-provider value with your own git provider as defined in git integrations.
When you run your pipeline you can select the trigger that will be used to fill in the values of all the Codefresh variables.
Why projects are better
Git clone steps are now required because pipelines are no longer bound to specific git repositories. Creating pipelines in the old way was restricting in the sense that all pipelines had to be connected to a specific git repository.
This made pipeline re-use very difficult. With the new project grouping the pipeline is not linked to specific repository. Instead it gets all information from triggers.
This means that you can easily re-use a single pipeline among different microservices by just adding more triggers.
If for some reason you still want a pipeline that always works against a specific git repository regardless of the trigger, then you can hard-code the details in the git clone step like below:
The pipeline above will always checkout project
foo regardless of the trigger that was used in order to launch it.