Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rolling changes out to staging takes long due to canary #727

Open
rogerthatdev opened this issue Dec 7, 2022 · 0 comments
Open

Rolling changes out to staging takes long due to canary #727

rogerthatdev opened this issue Dec 7, 2022 · 0 comments
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@rogerthatdev
Copy link
Contributor

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

  1. Activate the web-new-build trigger
  2. Observe triggers in the Cloud Build history page
  3. 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.

@rogerthatdev rogerthatdev added type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. and removed type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. labels Dec 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

1 participant