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

Reduce the test matrix #135

Open
sagikazarmark opened this issue Jul 26, 2023 · 4 comments
Open

Reduce the test matrix #135

sagikazarmark opened this issue Jul 26, 2023 · 4 comments
Labels
kind/enhancement Categorizes issue or PR as related to an improvement. lifecycle/keep Denotes an issue or PR that should be preserved from going stale.

Comments

@sagikazarmark
Copy link
Member

The current test matrix tests the operator on all supported Kubernetes versions with all supported Vault versions. However, for the operator we really should be testing Kubernetes compatibility, not Vault compatibility.

Although the Bank-Vaults CLI has way less integration tests (something we should probably change), failing an integration test due to a bug in Bank-Vaults itself does not mean anything from the operator's perspective.

I suggest reducing the test matrix in PRs to all supported Kubernetes versions and the latest Vault version.

We can keep running tests for all supported Vault versions on merges and in nightly builds, to make sure we catch integration errors, but I think we should reduce the size of the matrix in PRs.

WDYT?

@akijakya @ramizpolic

@sagikazarmark sagikazarmark added the kind/enhancement Categorizes issue or PR as related to an improvement. label Jul 26, 2023
@akijakya
Copy link
Contributor

While I agree that a bug in another repo should be caught there, I don't see how reducing the matrix should solve this issue, the time for the checks wouldn't really decrease as they are executed in parallel. Maybe we could put the same acceptance test in the bank-vaults repo as well, and use a pinned version of the operator in bank-vaults, a pinned version of bank-vaults in the operator and only update them when it is known for that version that it passes its checks?

@sagikazarmark
Copy link
Member Author

checks wouldn't really decrease as they are executed in parallel.

There is a limit on the amount of concurrent jobs we can run, so they don't all run parallel. We often have to wait for a set of jobs to complete before the next ones can launch.

@akijakya
Copy link
Contributor

There is a limit on the amount of concurrent jobs we can run, so they don't all run parallel. We often have to wait for a set of jobs to complete before the next ones can launch.

Oh I didn't notice that, just assumed that a rolling yellow circle means it is in progress!

Copy link

github-actions bot commented Dec 3, 2023

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 20 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. label Dec 3, 2023
@ramizpolic ramizpolic added lifecycle/keep Denotes an issue or PR that should be preserved from going stale. and removed lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. labels Dec 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Categorizes issue or PR as related to an improvement. lifecycle/keep Denotes an issue or PR that should be preserved from going stale.
Projects
Status: 🔖 Ready for work
Development

No branches or pull requests

3 participants