Automation with AWS 1.9 Release Notes

Evaluate remote conditions with the Get Systems Manager Parameter action

You can now use the Get Systems Manager Parameter action in applicable integrations to evaluate arbitrary remote conditions by persisting a JSON result shape that adheres to the action response format schema:

{
        'result': false,
        'errorMessage': "Workflow transition blocked due to a prerequisite condition being false"
}

This allows you to use an event-based architecture to decouple condition evaluation in AWS from condition evaluation in Atlassian to ensure that any prerequisites for your workflows are automatically checked right before dependent steps are initiated, thereby reducing cost and latency over using the Invoke Lambda Function action to synchronously call AWS services and third-party REST APIs at evaluation time.

Currently supported integrations are the Jira Service Management Automate with AWS if condition, the Jira Automate with AWS workflow condition and Automate with AWS workflow validator, and the Bamboo Automate with AWS task.

Inject remote configuration data and secrets with the Get Systems Manager Parameter action

You can now use the Get Systems Manager Parameter action in applicable integrations to inject arbitrary remote configuration data and secrets via the Systems Manager Parameter Store:

This allows you to maintain configuration data and regular secrets as (secure) parameters in the Systems Manager Parameter Store, and optionally maintain secrets in AWS Secrets Manager when you require more advanced secret lifecycle management.

Currently supported integrations are the Bamboo Automate with AWS task.

Adjust generated Bamboo variable namespace and scope

Similar to the Inject Bamboo variables task that has been included with Bamboo as of release 6.7, you can now specify the namespace and scope for Bamboo variables generated by the Automate with AWS task to enable more flexible build orchestration. You can now pass a variable between stages, pass a variable from a plan to a deployment project, and you can use multiple tasks within the same job without overriding variables from preceding tasks by adjusting the namespace. The task defaults to the preceding behavior with local scope and a custom.aws namespace so that this remains an opt-in choice for advanced use cases.