Automation
complete
David - Port team
Currently, Port can trigger workflows when a change is made in the software catalog, for example, trigger a webhook. This is done with the changelog listener. The main problem with the changelog listener is that only one trigger per blueprint can be defined, and each trigger is executed for any change in the catalog, without the ability to define rules for a specific trigger.
With the "Automations" feature, we plan to improve the changelog listener with the following capabilities:
- The ability to create rules that need to pass in order to trigger automation.
- Create multiple automations on a specific blueprint
- Adding many more invocation types when triggering automation, such as executing a Port action, executing a CICD pipeline, and updating entities in the catalog
This will enable scenarios such as:
- Sending a Slack message when the "Production readiness" scorecards changed from "Gold" to "Silver"
- Scaling a Cluster according to changes in the CPU usage
- Updating the "state" property of a service from "Healthy" to "Unhealthy" when a related incident opened in PagerDuty
Of course, these are just examples. The power of this capability is that each organization will be able to create automations based on their developer portal data and needs.
David - Port team
complete
We are excited to unveil our new Automations feature, designed to streamline and enhance your developer workflows. Automations allow you to automatically trigger workflows, alerts, and notifications based on changes within the software catalog, such as a new entity being created, a timer that expired, a scorecard change, or any other change in existing entity data. See docs to learn how to set up your first automation.
Gur Shafriri
Gur Shafriri
David - Port team
in progress