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
{{ message }}
This repository was archived by the owner on Feb 16, 2025. It is now read-only.
When making changes to website or api, staging changes to stage environment takes as long as it takes to roll out to prod due to the canary trigger. Could we reduce the time required for rolling out to staging by skipping canary and reserving it only for prod rollouts?
Steps to Reproduce
Steps to reproduce the behavior:
From a standing instance of emblem
Watch several web-canary-staging triggers show up.
Expected behavior
Since web-canary-staging functions exactly as web-canary-prod (only difference being the triggering action), there's no value in demonstrating canary trigger twice unless we intend to illustrate a difference based on environment. For demonstration purposes, I'd rather changes roll out to staging at 100% immediately.
Problem
When making changes to website or api, staging changes to stage environment takes as long as it takes to roll out to prod due to the canary trigger. Could we reduce the time required for rolling out to staging by skipping canary and reserving it only for prod rollouts?
Steps to Reproduce
Steps to reproduce the behavior:
From a standing instance of emblem
web-new-buildtriggerweb-canary-stagingtriggers show up.Expected behavior
Since
web-canary-stagingfunctions exactly asweb-canary-prod(only difference being the triggering action), there's no value in demonstrating canary trigger twice unless we intend to illustrate a difference based on environment. For demonstration purposes, I'd rather changes roll out to staging at 100% immediately.