Codefresh is a hosted and hybrid deployment pipeline solution. It may be used for testing and or deploying software. All steps in the pipeline run as Docker containers. Users can create reusable custom steps as well. Users can opt for the hosted version or host their runner on their own Kubernetes cluster.
Related Links
- Next Gen Deployments at Skillshare Webinar: A webinar I hosted for Codefresh sharing my experience building deployment pipelines for Skillshare.
Gotchas
Hooks and Steps Do Not Share Env Vars
Last encountered: Jan 2021
Codefresh Hooks appear to act like regular steps. You may
consider using a hook and cf_export
to set variables for all future
steps in the pipeline. This does not work. Hooks and steps do not
share the same context. In fact, they don’t even have access to
pipeline variables. Variables must be passed in directly to hooks.
Custom Steps Use Prerelease Versions
Last encountered: March 2021
Codefresh Steps use semantic versioning. If a pipeline step version is not declared then the “latest” version is used. Unfortunately “latest” includes prerelease versions.
Consider this step definition with the current version of 1.0.0.
foo:
type: myorg/custom
Then you release myorg/custom:2.0.0-beta1
. The foo
step will now
use the 2.0.0-beta1
release even though it’s not considered a stable
release.
There is no known solution pinning steps to always use the latest “stable” version. Codefresh has the “incubating” or “stable” channels for each step but these do not apply to releases. They only apply to how they’re presented in the UI.
Conflicting Step & Pipeline Services
Last encountered: March 2021
Codefresh Services may be declared at the pipeline level (they run for all steps) or at the step level (run for a single step). These are mutually exclusive. If you delcare pipeline services and step services then only the step services will run for that step.
Undefined Variable Literals
Last encountered: March 2021
Codefresh Variables may be referenced using ${{NAME}}
in the pipeline definition or as environment variables in commands
($NAME
or ${NAME}
depending on your shell and/or preference).
Say you reference ${{FOO}}
somewhere in the pipeline definition. If
FOO
is set then value is interpolated. If FOO
is not set then
value is left as a literal ${{FOO}}
. This is especially annoying
when dealing with optional variables (say those that may be set on
different triggers).
You’ll need to check if the value matches a variable format to decide if a true value is provided.
Here’s an example:
if echo "${FOO}" | grep -qE '\$\{\{.+\}\}'; then
echo "FOO not provided"
else
echo "FOO=${FOO}"
if
This is only possible inside commands. There is no way to check the variable in the pipeline definition. You may be able to do this with conditional steps though.
Custom Step Environment Variables
Last encountered: March 2021
Pipeline variables outside the system provided variables are not
automatically set on custom steps. I guess this is because of security
reasons? If this were true then any step would see all variables
(including secrets). This would make it possible for attacks to write
steps like env | upload-to-remove-server
. Anyway the end result is
that you cannot assume custom steps have access to pipeline
environment variables.
There is a workaround. You can use the stepTemplate
to capture env
variables and set them in the environment
list. You’ll have to deal
with the other gotcha that undefined variables are not
interpolated. Here’s an example:
stepsTemplate: |-
main:
name: example
image: example
environment:
- KUBE_CONTEXT=[[ default "${{KUBE_CONTEXT}}" .Arguments.KUBE_CONTEXT ]]
This template takes the KUBE_CONTEXT
argument or uses the
KUBE_CONTEXT
variable from the pipeline. If the KUBE_CONTEXT
is
not set then the step will receive a literal ${{KUBE_CONTEXT}}
for
KUBE_CONTEXT
. Step authors are advised to always validate env vars.
Exporting Environment Variables in Steps
Last encountered: April 2021
Exporting environment variables in your own steps and custom steps is
different. The docs refer to cf_export
. This is for your exporting
env vars in your own steps. Do not use this when writing custom steps.
Custom steps should echo export FOO=bar >> /meta/env
. Apparently the
/meta/env
is a special file that Codefresh reads when authoring
custom steps.
Pipeline Template Variable Limitations
Last encountered: March 2021
You may assume that you can reference variable using the ${{var}}
syntax anywhere in the pipeline YAML file. This is not the case.
These “pipeline” variables (or whatever they’re called) do not work
everywhere. They work most places.
Here’s an example.
steps:
build:
type: build
# ....
run:
image: foo
commands:
- echo ${{build}}
This does not work. The ${{build}}
step variable may only be used in
certain places in the YAML file.