You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce concept of phases having status conditions.
All examples are for illustration purposes only. The final API is open for debate.
The goal of status conditions (inspired by k8s) is to provide both:
Further insights into a phases current state
Surfacing conditions on phases in the UI can allow for integrators to add more information regarding the state of a resource in a given phase. This can be helpful for understanding if your change has
For example, developers could implement service condition functions to:
query their deployed service to ensure it is reachable / healthy / performant
query their deployment platform to understand whether or not the desired version matches current deployed version
Additionally, phases could automatically supplement their own source specific status conditions on their responses.
This is where we could surface the state of asynchronous actions made during promotion, for example:
(source: git) The status and location of open PRs associated with the last promotion attempt
There are many ways we could represent these statuses. They could be hung on the phase:
phases.New(glu.Name("staging"), pipeline, source,
core.PromotesFrom(staging,
core.WithStatusFunc("health", func(pipeline, phase glu.Metadata, resource*MyResource) (core.Status, error) {
// query some external source based on the metadata provided
},
))
Or we can do what we have done with the other integrations and support hanging a method of the resource:
func (r*MyResource) GetStatuses(pipeline, phase glu.Metadata) ([]core.Status, error) {
// query 0 or more external systems for statuses// adjust behaviour based on the phase in context
}
Integration point for conditional promotion rules
Once status conditions are available, it would be a useful integration point for hanging promotion gating conditions on.
Or perhaps the most flexible thing to do is take a func(pipe, phase glu.Metadata, r *MyResource, statuses []core.Status) bool {} for PromoteIf and let the caller use all the power of Go to decide.
The text was updated successfully, but these errors were encountered:
Introduce concept of phases having status conditions.
The goal of status conditions (inspired by k8s) is to provide both:
Surfacing conditions on phases in the UI can allow for integrators to add more information regarding the state of a resource in a given phase. This can be helpful for understanding if your change has
For example, developers could implement service condition functions to:
Additionally, phases could automatically supplement their own source specific status conditions on their responses.
This is where we could surface the state of asynchronous actions made during promotion, for example:
git
) The status and location of open PRs associated with the last promotion attemptThere are many ways we could represent these statuses. They could be hung on the phase:
Or we can do what we have done with the other integrations and support hanging a method of the resource:
Once status conditions are available, it would be a useful integration point for hanging promotion gating conditions on.
You could imagine something like the following:
Or perhaps the most flexible thing to do is take a
func(pipe, phase glu.Metadata, r *MyResource, statuses []core.Status) bool {}
forPromoteIf
and let the caller use all the power of Go to decide.The text was updated successfully, but these errors were encountered: