Pull Request Labels Can Now Dispatch Workflows

Label-driven environments, such as adding deploy to create a preview and removing it to tear it down, did not work with Atmos Pro: the label change reached your GitHub workflow, but Atmos Pro ignored it and dispatched nothing. Label changes are now trigger events of their own.

Configure the workflows next to the others in settings.pro:

settings:
  pro:
    enabled: true
    pull_request:
      synchronize: { workflows: *apply-wf-config }
      labeled: { workflows: *apply-wf-config }
      unlabeled: { workflows: *destroy-wf-config }

How It Behaves

Any label triggers them. There is no per-label filter in Atmos Pro. Filter in the GitHub workflow that runs atmos describe affected --upload, for example on github.event.label.name. The workflow also needs labeled and unlabeled under on.pull_request.types.
Push once after adding the blocks. Atmos Pro reads labeled and unlabeled from the definitions stored with the pull request's latest push, so a label changed before that push does nothing.
unlabeled always dispatches. Atmos Pro does not check whether anything was deployed first.
Same controls as a push. Label events show a check run and the status comment like a push and respect the same dispatch controls (pause, held dispatches, commit verification). They do not count toward the rapid-push cooldown, and a label change on a closed or merged pull request is ignored.
Nothing changes if you don't configure them. Repositories without labeled or unlabeled blocks see no new events, check runs, comments or Slack updates.

See Configure Atmos Stacks and the label-driven workflow example.

settings: pro: enabled: true pull_request: synchronize: { workflows: *apply-wf-config } labeled: { workflows: *apply-wf-config } unlabeled: { workflows: *destroy-wf-config }

How It Behaves

Any label triggers them. There is no per-label filter in Atmos Pro. Filter in the GitHub workflow that runs atmos describe affected --upload, for example on github.event.label.name. The workflow also needs labeled and unlabeled under on.pull_request.types.

Push once after adding the blocks. Atmos Pro reads labeled and unlabeled from the definitions stored with the pull request's latest push, so a label changed before that push does nothing.

unlabeled always dispatches. Atmos Pro does not check whether anything was deployed first.

Same controls as a push. Label events show a check run and the status comment like a push and respect the same dispatch controls (pause, held dispatches, commit verification). They do not count toward the rapid-push cooldown, and a label change on a closed or merged pull request is ignored.

Nothing changes if you don't configure them. Repositories without labeled or unlabeled blocks see no new events, check runs, comments or Slack updates.