Historically unless the deployment object being deployed contained changes, CD-as-a-Service completed an environments deployment instantly, and did not create a new ReplicaSet. Now all changes will follow the deployment strategy. This means, for example, that when deploying just a change to a configuration map, a new ReplicaSet will be created, and validated, just like any other change.
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