Added a new 'Borealis Progressive Deployments YAML' stage that can deploy using the same YAML as the Project Borealis CLI . This enables the Project Aurora stage to leverage all Borealis features even if they have not been added to the Spinnaker stage configuration UI.
Known Issues
You can only deploy to a single environment using the new 'Borealis Progressive Deployments YAML' stage
Sep
15
We've added a new element to the deployment graph called a Trigger Node which explains how a deployment was triggered by displaying the source system, initiating person, and trigger type. This allows anyone on the team to immediately know the source of a deployment, including who triggered it, and how it maps back to a pull request or commit.
When triggering from GitHub, additional source details will appear on the Trigger Node: PR title, PR number, commit SHA, branches, and in the event of a push tag trigger, the associated tag. Each element in the Source section is a deep link back to GitHub.
If context variables were passed with the trigger, they will appear in a Context Variables section on the Trigger Node.
Trigger Nodes will automatically show up on your deployment pipelines. Customers who have already configured a GitHub Action will need to adjust the workflow token permissions in their configuration to view the full set of Source Context information. This can be accomplished by adding a permissions block to your workflow, and adding a token to the GitHub action's env block.
Please refer to the updated documentation pages for more information.
Monitor Deployments
Use Armory's GitHub Action to Deploy Your App Using CD-as-a-Service
permissions:
contents: read
pull-requests: read
statuses: read
# Add GH_TOKEN to env in the cli-deploy-action step
- name: Deploy
env:
GH_TOKEN: '${{ secrets.GITHUB_TOKEN }}'
uses: armory/cli-deploy-action@main