When workflows fail with manual intervention set as the failure strategy, users now can set a timeout interval for how long to wait. Users can also specify an action to perform when the time out happens. This will help avoid unnecessary delays in your deployments and help automate your failure strategy. The default timeout is set to 2w for all the existing workflows. This can set at workflow as well as workflow phase level failures. Please refer to our docs for more details.
Harness has improved Slack and Email notifications contents to provide more relevant information at first glance. Now, you need not come to harness to get pipeline deployment details from Email notifications. Also, not just the environment but infra definition details are also present in the notifications so that you get clearly know which service is being deployed to which environment on what infrastructure.
Email Notification
Slack Notification
Harness now allows users to specify Helm Command Flags at the service level. Some of our users want to extend the Helm commands harness uses when performing a deployment. This enables the user to extend the behavior of our Helm Deployment without changing or impacting the order of operation for deployment. We support a variety of Helm Command Flags. For more info please check out the docs!
With this feature, Harness users have the ability to use Harness Delegates assuming Workload Identity to authenticate for GCP services (like accessing Artifacts from GCS and GCR, Google cloud build, etc.) instead of providing service account keys to Harness. Users can now select specific delegates (using delegate selectors) while creating a GCP cloud provider.
This makes managing key rotations simple as users just need to install the delegate in the GKE instance which has the workload identity setup.
Refer to the docs for more details.
Users can now Run ECS Tasks in Harness as a step in a Workflow. These containerized workloads can be spun up during deployment and will automatically terminate upon workload completion. The user will be able to view the task execution logs and the success or failure of the step.
This is extremely useful when running short term workloads like Smoke Tests, Health Checks, DB Migrations, and any containerized jobs.
We now support pulling tfvars files from a remote repository that is in a separate source code repository from the main Terraform files. This enables centralized infrastructure teams to integrate their Terraform Code in Harness as the core Infrastructure Provisioner while allowing application teams to bring in their tfvars files from their own repositories when configuring the Terraform Provision and Apply Steps in the workflow.
User's can now create a HashiCorp Vault Secrets Manager via API. This enables teams and users to onboard and automates the creation of their HashiCorp Vault Secrets Managers in Harness! You can also scope the configured secrets manager to specific applications and environments via the API. All the underlying secrets that are added will inherit the scoping as well.
We are changing the way we scope delegates to specific tasks. Users can now leverage the Delegate Selector and Profile Selectors and map them to specific Harness Tasks like AppDynamics for CV or Kubernetes for Continuous Delivery. By scoping by selector, it reduces the need to scope by individual delegates and you can cut down on the number of Delegate Scopes you configure. This method lets you explicitly map groups of delegates or delegates associated with a profile to tasks.
Check out the Docs for more details.
We are adding the ability to limit emails that can be sent using the email step only to addresses that have been registered with the Harness account. This prevents possible spoofing and phishing attacks.
NOTE: If **you currently have emails being sent to users in your organisation who are not registered as part of the Harness account, they will no longer receive the emails. The list of such emails will be available in the deployment details of the corresponding workflow. Please add these users to Harness account to receive emails going forward.
Now teams who have their own secrets manager or multiple secrets managers can leverage secrets manager scoping for applications and environments. This is extremely helpful for managing multiple secrets managers for different purposes. Users can now ensure specific secrets are used from Secrets Managers that are scoped to their application and or environment. Secrets also don't have to be individually scoped, they can inherit scope from their parent secrets manager.
