[CI] Test both migration patterns

Demonsthere commented 1 year ago

Preflight checklist

[X] I could not find a solution in the existing issues, docs, nor discussions.
[X] I agree to follow this project's Code of Conduct.
[X] I have read and am following this repository's Contribution Guidelines.
[ ] This issue affects my Ory Network project.
[ ] I have joined the Ory Community Slack.
[ ] I am signed up to the Ory Security Patch Newsletter.

Describe your problem

Currently we only test one set of values.yaml for applications. This causes us to test either initContainer or job automigration deployment patterns, and we can be (and have been) blind to changes that cause errors, like seen in https://github.com/ory/k8s/pull/563. To fix that we need to create copies or layers of overrides file to test both cases

Describe your ideal solution

hacks/values/hydra.yaml -> Default overrides for the application hacks/values/hydra-migration-job -> Subset of overrides to use specific migrations hacks/values/hydra-migration-init -> Other subset

then test it using layers like `helm template hydra . -f values.yaml -f hydra-migration-job.yaml

Workarounds or alternatives

have a ton of files with minor differences or set overrides using --set?

Version

yes

Additional Context

No response

DanyHenriquez commented 1 year ago

@Demonsthere You could use Helmfile with a values go template for this. That way you can have multiple setups to test without adding too much complexity.

Maybe we can work together on this to get a nice setup going?

Demonsthere commented 1 year ago

Hello there :) I was initially planning on using skaffold, to create multiple profiles and test them, but Helmfile is also a valid option. The point would be to have a matrix CI definition, which runs multiple cases for each chart, and runs in parallel to each other.

Feel free to reach out to me in the opensource slack if you want to discuss it in real time or a call. Cheers!

github-actions[bot] commented 7 months ago

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

open a PR referencing and resolving the issue;
leave a comment on it and discuss ideas on how you could contribute towards resolving it;
leave a comment and describe in detail why this issue is critical for your use case;
open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

ory / k8s