Continuous Delivery & GitOps release notes
These release notes describe recent changes to Harness Continuous Delivery & GitOps (NextGen SaaS). For release notes for Harness Self-Managed Enterprise Edition, go to Self-Managed Enterprise Edition release notes. For FirstGen release notes, go to Harness SaaS Release Notes (FirstGen).
- Progressive deployment: Harness deploys changes to Harness SaaS clusters on a progressive basis. This means that the features described in these release notes may not be immediately available in your cluster. To identify the cluster that hosts your account, go to your Account Overview page in Harness. In the new UI, go to Account Settings, Account Details, General, Account Details, and then Platform Service Versions.
- Security advisories: Harness publishes security advisories for every release. Go to the Harness Trust Center to request access to the security advisories.
Upcoming RBAC enhancements for Harness customers using Policy as Code
We are excited to announce an upcoming enhancement to our Role-Based Access Control (RBAC) within Harness.io, specifically for customers leveraging our Policy as Code capability. These changes aim to provide more refined and granular access control options, empowering you to have better governance over your Harness setup. Here are the key points regarding the upcoming update:
-
Release Date: The RBAC changes will be rolled out on October 30th, 2023 affecting all customers utilizing Policies and Policy Sets. This enhancement is a step forward in offering expanded and more granular RBAC options to our customer base.
-
Improved Access Control: The new feature will allow you to either select all or specify particular policies and policy sets to enable other Harness users to access a resource group. Through this, the resource groups can provide precise controls over which specific policies and policy sets the account admins desire users to access and edit.
-
Default Resource Groups Configuration: The default resource groups at the account, organization, and project levels will automatically have these configurations enabled with all policies and all policy sets. This adjustment ensures there is no alteration in policy experience for users leveraging the default Harness resource groups.
-
Existing Custom Resource Groups: For those who have created their own resource groups, we will extend the policy set and policy resources to those existing groups without selected configurations. It implies that you will need to opt-in and add those configurations to your existing user groups to grant user access.
-
Updating Resource Groups: You can conveniently update your resource groups either through our UI, API, or via our Terraform Provider.
Terraform Provider
Terraform Provider Note: Under the resource type, you can select either GOVERNANCE_POLICY or GOVERNANCE_POLICY_SET to make your updates.
API
Create: https://apidocs.harness.io/tag/Harness-Resource-Group#operation/createResourceGroupV2
Update: https://apidocs.harness.io/tag/Harness-Resource-Group#operation/updateResourceGroupV2
We highly encourage you to review these upcoming changes and make necessary adjustments to your Harness configurations to take full advantage of the enhanced RBAC features. For any questions or further assistance, please don't hesitate to reach out to Harness Support.
Deprecation notices
Helm 2
To safeguard your operations and protect against potential security vulnerabilities, Harness will launch an update to deprecate the Helm 2 binary from delegates with an immutable image type (image tag yy.mm.xxxxx
) later this month. For information on delegate types, go to Delegate image types.
Helm 2 was deprecated by the Helm community in November 2020 and is no longer supported by Helm. If you continue to maintain the Helm 2 binary on your delegate, it might introduce high and critical vulnerabilities and put your infrastructure at risk.
If your delegate is set to auto-upgrade, Harness will automatically remove the binary from your delegate. This will result in pipeline and workflow failures for services deployed via Helm 2.
If your development team still uses Helm 2, you can reintroduce the binary on the delegate. Harness is not responsible for any vulnerabilities or risks that might result from reintroducing the Helm 2 binary.
For more information about updating your delegates to reintroduce Helm 2, go to:
Contact Harness Support if you have any questions.
Kustomize
To safeguard your operations and protect against potential security vulnerabilities, Harness deprecated the Kustomize 3.4.5 binary from delegates with an immutable image type (image tag yy.mm.verno
). For information on delegate types, go to Delegate image types.
In place of Kustomize, Harness now uses the kubectl
binary to conduct Kustomize operations. Recent enhancements (versions 1.14 and higher) have made the kubectl
binary fully capable of supporting Kustomize operations. For more information, go to Kustomization in the Kubernetes documentation.
If your delegate is set to auto-upgrade, Harness automatically removed the binary from your delegate. This will result in pipeline and workflow failures for services that use Kustomize 3.4.5.
If your development team still uses Kustomize 3.4.5, you can reintroduce the binary on the delegate. Harness is not responsible for any vulnerabilities or risks that might result from reintroducing the Kustomize 3.4.5 binary.
For more information about updating your delegates to reintroduce Kustomize 3.4.5, go to:
Contact Harness Support if you have any questions.
June 2024
Version 1.42.4
Breaking changes
- Validations have been added to override variable names. Now, a new variable name cannot be saved if it starts or ends with a space. Also, validations have been added for special characters. This is a breaking change for the already saved invalid variable names. Hence, this change is enabled behind the feature flag,
CDS_OVERRIDES_VARIABLE_NAME_VALIDATIONS
. After enabling the feature flag, you can see that the variable names are being validated when creating or updating overrides. (CDS-97386, ZD-62711)
Fixed issues
- Validation for the pipelines with templates imported from Git failed. Typically, schema validation is done in the pipeline Get, Create, or Update calls. However, schema validation for pipelines imported from Git (with templates) is done without resolving the templates because it's an expensive operation. Therefore, schema validation in the async validate call to identify any schema errors causing validation failure. Note that the issue only happens with imported pipelines with templates from Git currently. (PIPE-18537, ZD-61841)
- Null Pointer Exception occurred in the Verify step. Added null point checks to avoid this error in the future. (CDS-97388)
- Pipeline execution showed inconsistencies. This issue is fixed by fixing a retry bug with the delegate's Git client where it did not retry on specific errors. (CDS-96877, ZD-63321)
- Service failed intermittently when fetching the
ECR_ARTIFACT_TASK_NG
artifact. This issue is fixed by optimizing ECR calls by reducing the number of client creation calls and reusing the clients by passing them and eventually using them to make calls instead of creating clients every time. (CDS-96861, ZD-63061) - The Execution History page broke when numbers were used in the Tags field. This issue is fixed by converting the string holding the number to string type before applying string methods on the variable. (CDS-96636)
- When trying to resolve the expressions in the File Store scripts, Harness encountered a self referencing expression. Due to this condition, the resources associated with two Harness services were exhausted. A code change fixed this issue by preventing such pipeline executions. This item requires Harness Delegate version 24.06.83304. For information about features that require a specific delegate version, go to the Delegate release notes. (PIPE-19585, ZD-64579, ZD-64580)
Version 1.41.6
Usability enhancement
- Harness Approval step usability has been enhanced. Earlier, during pipeline execution with the Harness Approval step, the approval actions, Approve and Reject had low visibility in the Executions view. This has been enhanced to match with the Console view where the Approve and Reject actions are available in the top section. You must now provide the Approval inputs upon clicking Approve or Reject.
Early access
- Harness now lists all pipeline executions including retired and child executions in the Executions page. This feature is behind the feature flag,
PIE_SHOW_ALL_EXECUTIONS_FILTER
. Contact Harness support to enable it. (PIPE-18492, ZD-64066)
Fixed issues
- Updates made to stage variables did not reflect in the pipeline. When adding a new allowedValue in a template, the changes were not getting propagated to the pipeline as it was getting treated as subset. This issue was caused by a change made in the code to allow subsets of values in allowedValues in a nested pipeline/template. Harness is reverting this change, and will support exact allowedValues in pipeline/template during reconciliation. Some customers may face reconciliation errors if they are using subset allowedValues already. (PIPE-19102, ZD-62929)
- Running a pipeline returned an unclear error message,
Invalid request: Cannot create pipeline entity due to Unexpected token (FIELD_NAME), expected END_OBJECT: expected closing END_OBJECT after type information and deserialized value at [Source: (StringReader); line: 13124, column: 1]
. This issue is fixed by providing a meaningful error message for thegetStageExecutionList
flow. (PIPE-16557, ZD-60649) - Null pointer exception occurred when populating instrumentation data for sending events for telemetry. This issue occurred because some JsonNode objects returned null while called using GET method. This issue is resolved by adding null checks for the JsonNode objects. (PIPE-16452)
- Service steps failed intermittently when fetching the ECR_ARTIFACT_TASK_NG artifact. This issue is fixed by optimizing ECR calls by reducing the number of client creation calls and reusing the clients by passing them and eventually using it to make calls instead of creating clients every time. (CDS-96861, ZD-63061)
- Terraform configuration for a monitored service returned the
500
response code. This issue occurred due to incorrect un-marshalling of Terraform configuration to the JSON object for the API request. This led to backend validations failing and causing the500
response code. This issue is fixed by adding more validations/null checks in the backend. (CDS-96374, ZD-62737)
May 2024
Version 1.39.4
Fixed issues
- Fixed an issue where the MS Teams notifications didn't show the event names. Now, the pipeline end event appears as "ended" and the pipeline success event appears as "succeeded" in notifications. (PIPE-18855, ZD-62684)
- For a pipeline with bidirectional sync enabled, the file name change in GitHub was not properly reflected in the Harness UI. This issue is fixed by enhancing the cache handling for files. (PIPE-18828, ZD62791)
- Step group templates did not appear when selecting Use Template on an Approval stage. This issue is fixed. You can now create a step group template with the Approval stage, and use them as step entities in the Approval stage. (CDS-96930, ZD-63556)
- The HTTP step's Request Body field stretched horizontally to fit lengthy expressions. This issue is fixed. (CDS-96839, ZD-63344)
- Fixed an issue where users were unable to save YAML changes when creating a new infrastructure definition. (CDS-96396, ZD-62801, ZD-63997)
- The TerraformCloud Run step did not fail if the Terraform Apply step failed. This issue occurred because we were not checking the status of Terraform Apply after streaming logs. If Apply started, the step passed even if the Apply step did not complete. The step failed only when the Apply step failed to start, but not if it failed midway. This issue is fixed. The TerraformCloud Run step now fails if the Apply step fails midway, allowing users to use appropriate failure strategies. (CDS-96089, ZD-62254, ZD-63371)
- Fixed an issue where runtime expressions and values were not supported for Helm Values files in the Update GitOps Apps step. (CDS-96005)
- The Resource Constraint pop-up didn't show the ongoing execution details in the pipeline execution console view. This issue is fixed. (PIPE-18831, ZD-62825)
Version 1.38.2
Early access
- You can now select a monitored service template from a Verify step during runtime. This feature is currently behind the feature flag,
CV_MONITORED_SERVICE_TEMPLATIZATION
. To enable a feature flag in your Harness account, contact Harness Support. For more details, go to Templates and templatization in CV. (CDS-80059)
Limitations
- The
$HOME
variable does not resolve to the home path when creating a directory or file path because the value is being used as a string. You cannot pass any value to the$HOME
variable using expressions in a pipeline level. (CDS-96691, ZD-62711)
Fixed issues
-
There was a recent change to the expression resolution fallback logic to call the fallback only for customers who has the feature flag,
CDS_DISABLE_FALLBACK_EXPRESSION_ENGINE
set to true. The current value is false for everyone. However, during this change, the fallback was not being called for customers who has set the feature flag to true, causing the expression to fail. This issue is fixed by correctly calling the fallback in case of failures and adding UTs to handle it. (PIPE-19013, ZD-63175, ZD-63194) -
Fixed an issue where pipelines with IDP stages were not generating the correct pipeline execution URL. (PIPE-18322, ZD-60366)
-
Custom stages were not displaying wait status for the Approval step. Earlier, the stages were not marked as waiting when the steps went into waiting status. Now, the stage nodeExecution is marked as waiting when the step goes into waiting status. And, the stage is resumed when all the steps under that stage are resumed. (PIPE-15829, ZD-61238)
-
Input sets displayed wrong path even when the correct path exist. This issue is fixed. Now, selecting an infrastructure definition from a repository that is different from the parent input set's repository will no longer return an error. (CDS-96589, ZD-62984)
-
Unable to send
GitEntityFindInfoDTO
for Docker artifact resources. This issue occurred because the Git metadata was not being passed as a query parameter in API calls. This issue is resolved by making backend changes to resolve the YAML. (CDS-96379) -
The error that appeared when a pipeline was missing a reference to Harness resources like service, environment, etc, appeared only for a small amount of time and didn't allow users to see necessary details. This issue is fixed. The error message now stays until users close it manually. (CDS-96302, ZD-62677)
-
Trigger activity history cleared when updating trigger. This issue is fixed by changing the Trigger Activity History retention duration to 6 months instead of 7 days. (CDS-95729, ZD-61782)
-
The nav header panel of the Harness UI was not collapsible. The panel is now collapsible and appears when you hover over it. (CDS-95698, ZD-61706, ZD-61707)
-
Artifact builds were not loading if its entities were in a different repository. This issue is fixed.(CDS-95196, ZD-60805)
-
The fixedValue field is mandatory for backend as well now. Earlier, Harness has validations in place to ensure that fixedValue in the UI is not null. This change is implemented in the backend as well for consistency for API contract from backend as well as UI. (CDS-94414)
-
Multiple infrastructure definitions were pointing to the same underlying infrastructure and deployed the same service, and doubled the instance count. This issue is fixed. (CDS-88736)
You can run the following API to check duplicate instances in your account.
curl --location 'https://app.harness.io/gateway/ng/api/instancestats/duplicates?routingId=<accountId>&accountId=<accountId>&orgIdentifier=<orgId>' \
--header 'Authorization: Bearer <token>'You can refer to
instanceKey
to identify the duplicate instance. For example, for Kubernetes, the format isK8sInstanceInfoDTO_<podName>_<namespace>_<imageName>
.
Version 1.37.6
Fixed issues
- Fixed an issue where users were not able to configure Job Parameters for a Jenkins job. (CDS-95864, ZD-61927)
- The Feed field in the Artifact Details page for Azure artifacts threw a null pointer exception error. This issue occurred due to the presence of a whitespace in the Azure project name due to which Harness was not able to parse the URL as an URI object. This issue is fixed by encoding the URL to convert the whitespace in the project name to
%20
as per the UTF-8 standard to avoid the null pointer exception. (CDS-95752, ZD-61696)