Skip to main content

Release 2026.6.0

· 10 min read
meshcloud

Release period: 2026-02-05 to 2026-02-11

This release includes the following issues:

  • Fix Building Block Summary Mentions Displaying as Escaped HTML
  • Ephemeral API Keys for Azure DevOps Pipelines in Building Block Definitions
  • Invalid Currency Codes are Rejected in Resource Usage Reports
  • Sensitivity Toggle Disabled for Existing Building Block Inputs
  • Ephemeral API Keys for GitHub Actions in Building Block Definitions
  • System Generated Inputs for Async Building Blocks
  • meshObject API Lifecycle Information Now in Status Section
  • Improved Import of Existing Groups Into Azure Administrative Units
  • Improvements for Building Block Definition Version API
  • Approval Requirement In Access Management v2
  • Building Block Run Updates Are No Longer Lost Due to Timing Issues
  • Building Block Definition Permissions Preserved When Creating Drafts
  • Building Block Input Keys Must Be Unique
  • Improved Secret Handling in Building Block Implementation Forms
  • Improved Secret Handling in meshIntegration API
  • Improved API Key Permission Selection Experience

Ticket Details​

Fix Building Block Summary Mentions Displaying as Escaped HTML​

Audience: User

Description​

We fixed an issue where @buildingblock, @project, and @tenant mentions in building block summary markdown were displayed as escaped HTML text instead of rendered elements. Mentions now correctly display as interactive badges that load and show the referenced resource information.

Ephemeral API Keys for Azure DevOps Pipelines in Building Block Definitions​

Audience: User

Description​

Building block definitions using Azure DevOps Pipelines now support ephemeral API keys when you configure permissions on the building block definition. This enables building blocks to interact with meshStack programmatically without requiring manually managed credentials.

How to use​

When you create or edit a building block definition using Azure DevOps Pipeline implementation and select one or more permissions, meshStack automatically generates a workspace-scoped API key and provides it as the MESHSTACK_API_TOKEN pipeline variable. Your Azure DevOps Pipeline can use this token to authenticate API requests to meshStack.

Additionally, if you enable asynchronous execution mode for your building block definition, meshStack also provides MESHSTACK_RUN_URL and MESHSTACK_RUN_TOKEN as pipeline variables. These allow your Azure DevOps Pipeline to report status updates and results back to meshStack for the specific building block run.

The ephemeral API keys are automatically managed by meshStack - they are created when the building block run starts and have limited scope to ensure security. You don't need to manually create or manage any API keys.

Invalid Currency Codes are Rejected in Resource Usage Reports​

Audience: User

Description​

We now validate currency codes when importing resource usage reports via the meshResourceUsageReport API. Only valid ISO 4217 currency codes (such as USD, EUR, GBP) are accepted. If you submit a usage report with an invalid currency code, the API will return a clear error message indicating which currency code is invalid. This validation prevents data inconsistencies in your billing and chargeback data, ensuring that all financial information uses standardized currency codes.

How to use​

When importing resource usage reports, make sure all line items use valid ISO 4217 currency codes. If you receive an error about an invalid currency code, check the currency field in your usage report and correct it to use a standard three-letter currency code like USD, EUR, or GBP.

Sensitivity Toggle Disabled for Existing Building Block Inputs​

Audience: User

Description​

We strengthened security by preventing changes to the sensitivity setting of existing building block definition inputs. Once an input is marked as sensitive (encrypted), it cannot be downgraded to non-sensitive for security reasons. The sensitivity toggle in the building block definition editor is now automatically disabled for existing inputs to clearly indicate that this setting cannot be changed.

Ephemeral API Keys for GitHub Actions in Building Block Definitions​

Audience: User

Description​

Building block definitions using GitHub Actions now support ephemeral API keys when you configure permissions on the building block definition. When using the "Pass only API URL" mode, the API token is automatically provided as a workflow input variable (MESHSTACK_API_TOKEN), allowing your GitHub Action workflows to authenticate with the meshStack API securely. This enables building blocks to interact with meshStack programmatically without requiring manually managed credentials.

How to use​

When you create or edit a building block definition using GitHub Actions implementation and select one or more permissions, meshStack automatically generates a workspace-scoped API key and provides it as the MESHSTACK_API_TOKEN workflow input. Your GitHub Action workflow can use this token to authenticate API requests to meshStack.

Additionally, if you enable asynchronous execution mode for your building block definition, meshStack also provides MESHSTACK_RUN_URL and MESHSTACK_RUN_TOKEN as workflow inputs. These allow your GitHub Action workflow to report status updates and results back to meshStack for the specific building block run.

The ephemeral API keys are automatically managed by meshStack - they are created when the building block run starts and have limited scope to ensure security. You don't need to manually create or manage any API keys.

System Generated Inputs for Async Building Blocks​

Audience: User

Description​

Asynchronous building block definitions now automatically receive two new system-generated inputs: MESHSTACK_RUN_URL and MESHSTACK_RUN_TOKEN. These inputs enable building block implementations to report status updates and results back to meshStack using the meshObject API without the need of finding the right URL manually and creating an admin scoped API key. This makes updating the run status and results more secure and easier, especially for building block implementations running outside of meshStack (e.g., GitHub Actions, Azure DevOps, or OpenTofu with async enabled).

How to use​

Use the MESHSTACK_RUN_URL and MESHSTACK_RUN_TOKEN environment variables in your async building block implementations to report status and results. For example, in a GitHub workflow or Azure DevOps pipeline, POST to the run URL with the token to update the run status. These variables are automatically available when async mode is enabled. Existing asynchronous building block definitions will receive these inputs upon the next update to their implementation settings.

meshObject API Lifecycle Information Now in Status Section​

Audience: User

Description​

The meshObject API now consistently provides lifecycle information (such as creation and deletion timestamps) in the status.lifecycle section instead of the metadata section. This change affects meshPlatform, meshPlatformType, and meshIntegration objects. The API now follows a clearer separation of concerns: metadata contains identifiers and ownership information, while status contains runtime state and lifecycle information.

Improved Import of Existing Groups Into Azure Administrative Units​

Audience: User

Description​

We fixed an issue where existing Azure groups could not be correctly imported into an administrative unit (AU). The fix also adds better error handling and reporting for edge cases like missing or duplicate groups.

Improvements for Building Block Definition Version API​

Audience: User

Description​

We improved the API for Building Block Definition Versions so you can manage permissions for ephemeral API keys that are used when running Building Blocks based on a specific Building Block Definition Version. Furthermore, we added lifecycle information to the status subsection of Building Block Definition Versions.

Approval Requirement In Access Management v2​

Audience: User

Description​

If your organization has enabled 4EyePrinciple, you will now be prompted to provide a reason when adding or editing user access to workspaces and projects. This approval workflow (also known as the 4-eye principle) ensures that access changes are reviewed and authorized by multiple people for better security and governance. When 4EyePrinciple is enabled, a "Reason" field automatically appears in the add and edit user forms, requiring you to explain why the access change is needed. Your request will then need to be approved by a workspace or project owner before the access change takes effect. This works for both adding individual users and adding multiple users at once, where a single reason applies to all users being added. If approval requirements are not enabled for your organization, users are added or edited immediately without requiring a reason.

Note: This change only affects customers who have access to the new access control v2 feature. If you are using the standard access control interface, this change does not apply to you.

Building Block Run Updates Are No Longer Lost Due to Timing Issues​

Audience: User

Description​

Fixed a bug where building block run updates could be lost when a late update from the coordinator arrived shortly after a runner had already registered its execution status. This could lead into seemingly stuck building blocks.

Building Block Definition Permissions Preserved When Creating Drafts​

Audience: User

Description​

Building block definition permissions (ephemeral API keys) are now correctly preserved when creating draft versions from published versions. Previously, these permissions were silently lost during the draft creation process, requiring manual reconfiguration.

Building Block Input Keys Must Be Unique​

Audience: User

Description​

Building block definition inputs now require unique input keys. When creating or editing building block definitions, the system validates that no two inputs share the same key, both in the panel and via the API. This prevents configuration errors and ensures clear, unambiguous input references.

Improved Secret Handling in Building Block Implementation Forms​

Audience: User

Description​

We improved the way you manage secrets (like SSH private keys) when configuring building block definitions. The new implementation now properly handles secret data using a secure embedded format, ensuring that existing secrets are preserved when you update other properties without re-uploading them.

How to use​

When editing a building block definition with Terraform implementation, you can now see a clear indication when an existing SSH private key is configured (displayed as "*****"). You only need to upload a new key if you want to change it - otherwise, the existing key will be preserved automatically. This makes it easier and safer to update other implementation settings without accidentally removing or exposing sensitive credentials.

Improved Secret Handling in meshIntegration API​

Audience: User

Description​

The meshIntegration API now uses an improved secret handling approach for integration secrets like GitHub App private keys and Azure DevOps personal access tokens. Previously, GET responses returned a placeholder value for secrets, which made it impossible to detect configuration drift. Now, secrets are returned with a hash value that enables drift detection while maintaining security by never exposing actual secret values. This uses the same concept as meshPlatform configurations and building block definitions. This is a breaking change, so existing API clients need to adapt to the new secret representation structure.

Improved API Key Permission Selection Experience​

Audience: User

Description​

We have redesigned the API Key permission selection experience to make it much easier for you to browse and pick the right permissions for your Workspace or Admin API keys. The new interface groups permissions more clearly and provides helpful descriptions, so you can confidently select the access you need. This update also applies to the recently introduced ephemeral API keys for Building Block Definitions, making it simple to grant just the right permissions for automation and integration scenarios.

How to use​

When creating or editing an API key, you will now see a new permission selection dialog. Permissions are grouped by category, and you can expand each group to learn more about what each permission allows. For ephemeral API keys used in Building Block Definitions, you can quickly select only the permissions required for your automation. This helps you follow the principle of least privilege and improves security for your integrations.