Welcome to the release notes for our on-premises releases.

Features and enhancements are divided into those in general availability and those currently in Beta.

You’re probably familiar with the`fail_fast` flag available for steps in Codefresh pipelines. The flag determines the pipeline’s behavior when there is a step failure. Accordingly, when set to`false`, the pipeline continues execution and returns a Build status of`Build completed successfully`.

But what if you want to indicate that a step failed in the Build status even when the pipeline completes execution? Enter our new`strict_fail_fast` flag! Now, you can indicate that the step failed execution by simply adding`strict_fail_fast` to the step and setting it to`true`. After the pipeline completes execution, the Build status is designated as Failed.

step_name:

type:git-clone

title:Step Title

description:Step description

credentials:

fail_fast:false

strict_fail_fast:true

when:

branch:

ignore:[ develop ]

on_success:

on_fail:

on_finish:

retry:

For details, check out the**Fields** table in the documentation for the different step types, as in the[`git-clone` step]({{site.baseurl}}/docs/pipelines/steps/git-clone/) for example.

We are happy to announce a highly-requested feature: the ability to use_empty variables_ in Codefresh pipelines.

Now, you can add variables without any values to entities in Codefresh, whether it's a project, pipeline, or trigger. The enhancement unlocks a myriad of possibilities that were previously unavailable.

{% include

image.html

lightbox="true"

file="/images/whats-new/jan24/rel-notes-jan-24-empty-variables.png"

url="/images/whats-new/jan24/rel-notes-jan-24-empty-variables.png"

alt="Empty variables in a Codefresh project"

caption="Empty variables in a Codefresh project"

max-width="60%"

%}

Remember that encryption is not supported for empty variables. The priority for variable overrides remains unchanged.

For details, see[User-defined variables in pipelines]({{site.baseurl}}/docs/pipelines/variables/#user-defined-variables).

Our newest enhancement to pipeline builds is designed to increase collaboration and productivity! How? Instead of redefining build settings manually, you can effortlessly share pipeline build settings with colleagues who have access to the same account.

**How does it work?**

By sharing build settings, you enable colleagues to pre-populate build configurations without the need for redundant manual input. This feature is useful for various scenarios, whether it's for testing automation integration with third-party tools or triggering pipelines in specific situations.

**Customizing build settings**

You can override any existing setting - simulate a different trigger, select a different branch, modify existing or add new build variables, and even modify the build behavior.

With a click of the**Share build settings** button, Codefresh generates a unique URL. The URL includes modified and new settings as query parameters. Encrypted variables are excluded to ensure data protection.

{% include

image.html

lightbox="true"

file="/images/whats-new/jan24/rel-notes-jan-24-share-run-configuration.png"

url="/images/whats-new/jan24/rel-notes-jan-24-share-run-configuration.png"

alt="Share build settings"

caption="Share build settings"

max-width="40%"

%}

For details, see[Share build run settings]({{site.baseurl}}/docs/pipelines/run-pipeline/#share-build-run-settings).

At Codefresh, we highly value your feedback and are committed to continually enhancing your experience. In response to your feedback, we introduced the ability to configure the default restart behavior for failed steps in a pipeline at the account level.

{% include

image.html

lightbox="true"

file="/images/whats-new/jan24/rel-notes-jan-24-restart-failed-step.png"

url="/images/whats-new/jan24/rel-notes-jan-24-restart-failed-step.png"

alt="Restart from failed step in Pipeline Settings"

caption="Restart from failed step in Pipeline Settings"

max-width="50%"

%}

When enabled (the default), the user can restart the pipeline directly from the failed step. Otherwise, users can only restart the pipeline from the beginning.

By default, individual pipelines are configured to inherit the account setting.

Note that this does not impact existing pipelines.

Being able to configure the restart behavior for failed steps centrally simplifies management and ensures consistency across pipelines, without the need for individual adjustments.

Imagine a scenario where you’re onboarding a large team of developers. You can disable failed-step restart for the account, and have the pipelines use the account-level setting, saving valuable time and promoting a consistent experience.

You can always change the behavior at any time based on evolving requirements. And users have the flexibility to override the account-level behavior for individual pipelines based on specific needs.

For details, see[Restarting from failed steps]({{site.baseurl}}/docs/pipelines/configuration/pipeline-settings/#restarting-from-failed-steps).

As you're aware, Codefresh is continually enhancing our typed step library in the Marketplace.

When typed steps in pipelines lack a specified version, Codefresh automatically associates them with the latest version of the step. To avoid potential issues with breaking changes in typed steps, we now provide a warning if there are steps in your pipelines without an explicit version number.

{% include

image.html

lightbox="true"

file="/images/whats-new/jan24/rel-notes-jan-24-typed-step-warning.png"

url="/images/whats-new/jan24/rel-notes-jan-24-typed-step-warning.png"

alt="Warning for typed steps without version numbers"

caption="Warning for typed steps without version numbers"

max-width="60%"

%}

For details, see[Versioning for typed steps]({{site.baseurl}}/docs/pipelines/steps/#versioning-for-typed-steps).

Here's an enhancement which contributes to workflow optimization - a new field in our`git_clone` step: the`exclude_blob` field.

Filter out blob files from the Git repository and further streamline your development process. Fewer unnecessary files to clone and faster cloning times!

For blobless cloning, simply set`exclude_blob` to`true`. To always include blob files, you can retain the default value of`false`.

For details, see[Fields in git-clone step]({{site.baseurl}}/docs/pipelines/steps/git-clone/#fields).

With this update, you can effortlessly add tags when you create a pipeline, further streamlining the pipeline creation process. Add tags as you usually do, and they are instantly available in both the General Settings and the Permissions panel.

{% include

image.html

lightbox="true"

file="/images/whats-new/jan24/rel-notes-jan-24-tags-in-create-pipeline.png"

url="/images/whats-new/jan24/rel-notes-jan-24-tags-in-create-pipeline.png"

alt="Add tags when creating pipeline"

caption="Add tags when creating pipeline"

max-width="40%"

%}

We’re thrilled to introduce a significant enhancement simplifying troubleshooting Argo CD applications within Codefresh.

With our new Diff View feature, you can instantly view the differences between the current and the desired states of out-of-sync applications.

The Diff View option displays all the updated resources within the application, allowing you to easily pinpoint changes and swiftly identify the root cause of the sync failure.

If you have selected an application, the Diff View option is available in the context menu at the top right of the page. The option is enabled whenever the application is out-of-sync.

Diff View for application resources is supported from Runtime v1.0.38 and higher. <!--- To enable this feature, you need to turn on the `appDiffView` feature flag. -->

For details, see[Analyze out-of-sync applications with Diff View]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/#analyze-out-of-sync-applications-with-diff-view).

Tailor the timeout thresholds for sync operations for different applications, and receive instant alerts when the sync duration exceeds the threshold defined.

Instead of waiting indefinitely for syncs to complete and then navigating through the GitOps Apps dashboard, Codefresh provides you with timely warnings to proactively investigate and resolve sync issues.

Just include an annotation in the application's YAML, and either retain the default timeout of 30 minutes (also Argo CD's default for sync operations), or change it as needed.

Codefresh will display a warning in the**Warnings/Errors** panel for the app when the sync operation exceeds the timeout.

{% include

image.html

lightbox="true"

file="/images/whats-new/jan24/rel-notes-jan-24-sync-timeout.png"

url="/images/whats-new/jan24/rel-notes-jan-24-sync-timeout.png"

alt="Sync timeout warning for Argo CD applications"

caption="Sync timeout warning for Argo CD applications"

max-width="70%"

%}

For details, see[Configure sync-timeout for Argo CD applications]({{site.baseurl}}/docs/deployments/gitops/manage-application/#configure-sync-timeout-for-argo-cd-applications).

We introduced a couple of usability enhancements for Argo CD applications in Codefresh.

To more accurately represent the live deployment status of the selected application in the Timeline tab, we now clearly differentiate between current and historical deployments.

The Current Release is prominently displayed as a dedicated deployment record at the top of the Timelines tab, tagged as the Current Version. It is followed by the list of Previous Releases.

{% include

image.html

lightbox="true"

file="/images/whats-new/feb24/rel-notes-feb24-current-release-record.png"

url="/images/whats-new/feb24/rel-notes-feb24-current-release-record.png"

alt="Current Release deployment record in Timeline tab"

caption="Current Release deployment record in Timeline tab"

max-width="70%"

%}

* To prevent confusion with duplicate statuses, the application's health and sync statuses are now exclusively displayed and tracked within the Application Header.

* To validate that the current release as the live state, the release revision in the deployment record mirrors the sync revision displayed in Last Sync Result.

For details, see[Monitoring deployments for selected Argo CD application]({{site.baseurl}}/docs/deployments/gitops/applications-dashboard/#monitoring-deployments-for-selected-argo-cd-application).

The Configuration tab displays handy links to the application's GitOps Runtime, Git Source, and YAML manifest in the Git repo.

{% include

image.html

lightbox="true"

file="/images/whats-new/feb24/rel-notes-feb24-apps-quick-links.png"

url="/images/whats-new/feb24/rel-notes-feb24-apps-quick-links.png"

alt="Quick links for application in Configuration tab"

caption="Quick links for application in Configuration tab"

max-width="70%"

%}

We are glad to announce that you can now view and download logs for individual GitOps Runtime components!

Previously available for legacy CLI Runtimes, this functionality is now back for Helm GitOps Runtimes, with online viewing in our smart terminal and offline downloads as you need.

As a reminder, here's where you can find the**View logs** option:

{% include

image.html

lightbox="true"

file="/images/whats-new/jan24/rel-notes-jan-24-runtime-component-log.png"

url="/images/whats-new/jan24/rel-notes-jan-24-runtime-component-log.png"

alt="View logs for GitOps Runtime components"

caption="View logs for GitOps Runtime components"

max-width="70%"

%}

For details, see[View/download logs for GitOps Runtime components]({{site.baseurl}}/docs/installation/gitops/monitor-manage-runtimes/#viewdownload-logs-for-runtime-components).

We've recently upgraded Argo Events to its latest version, v1.9.0, ensuring you can leverage all enhancements. For detailed information about the changes in this version, please refer to the[Argo documentation](https://github.com/argoproj/argo-events/releases){:target="\_blank"}.

Please be aware that this upgrade may introduce a potential breaking change for existing event sources that have defined`githubBaseUrl` without defining`githubUploadURL` which is required. In such cases, event sources will fail to sync, and the Git Source application will return a`..githubUploadURL is required when githubBaseURL is set` error.

To address this, you'll need to edit the event source YAMLs and add`githubUploadURL` where required.

As we have transitioned to Helm-based Runtimes for GitOps, we have permanently deprecated the CLI-based installation for GitOps Runtimes.

Feature Flags are divided into new Feature Flags released in the current version, and changes to existing Feature Flags which are now enabled by default.

**New Feature Flags in v???**

The table below describes the_new_ Feature Flags in the Codefresh On-Premises release v???.

{: .table .table-bordered .table-hover}

| Feature Flag| Description| Default Value|

| -----------| ---------------------------------------------------------| -------------------------|

|`abacAndRule`| When enabled, supports creating ABAC rules for entities in Codefresh pipelines using "AND". <br>See[Pipelines: Enhanced RBAC with AND logic for tags](#pipelines-enhanced-rbac-with-and-logic-for-tags) in this article.| TRUE|

**Updated Feature Flags in v???**

The table below lists existing Feature Flags which have been updated by default to be either enabled (set to_TRUE_), or disabled (set to_FALSE_).

{: .table .table-bordered .table-hover}

| Feature Flag| Description| Default Value|

| -----------| ---------------------------------------------------------| -------------------------|

|`accountInfoCopyButton`| When enabled, the account ID is added to the URL. When sharing the URL with the account information, recipients can seamlessly switch accounts.|_FALSE_|