search

metal3-io / baremetal-operator

Bare metal host provisioning integration for Kubernetes
Apache License 2.0
554 stars 241 forks source link

E2E: Make the `hack/e2e` folder architecture agnostic #1487

Open kashifest opened 7 months ago

kashifest commented 7 months ago

Currently the scripts under the hack/e2e folder would work locally only for linux-amd64 architecture. As an darwin-arm64 user, I would expect the script works locally for me as well atleast. We can add other architectures as well but atleast these two can be supported minimally.

lentzi90 commented 7 months ago

To clarify and continue the discussion, I would not expect ci-e2e.sh to work locally. It is for CI as evident by the filename. However, I definitely want a way for developers to run the e2e tests locally and that is what I think this issue should be about. Not every script in hack needs to work on every machine.

For CI we need to have one specific configuration that works. For developers we need flexibility more than anything. In my opinion we should not expect developers to run scripts that install htpasswd or any other things system wide at all. Instead we should document the dependencies so it is easy to set up a suitable environment in whatever way they like. I would expect people to want to run the tests on mac, windows, all kinds of linux distros, etc. We cannot cover everything so the most important part is to make it flexible. With that said, we can probably provide some solution that works for 80 %, and that we should do. So let's say a script that works on ubuntu and mac + docs for how to do it in any other situation

tuminoid commented 7 months ago

Very much agreed with @lentzi90 . It would go a long way if you had some sort of verify script, that'd tell you (but not try install) if you're missing something. Then it is up to developer to install said dependencies. If its not too complex, we may provide support for some OS as mentioned, since we need to do it for CI as well. We need to be extra careful in naming the scripts so people don't end up destroying their OS by running CI scripts that install or remove software and configs at whim.

We might also want to reconsider placing the CI scripts elsewhere than in hack? So far the scripts have been more or less developer friendly and safe to run (linters etc). Our makefiles/scripts are not super consistent within repo, and even less, between repos as well. We should at some point make it consistent how things are expected to be run.

Rozzii commented 7 months ago

/triage accepted /kind feature

metal3-io-bot commented 4 months ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

tuminoid commented 4 months ago

/remove-lifecycle stale

metal3-io-bot commented 1 month ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

Rozzii commented 1 month ago

/remove-lifecycle stale /lifecycle frozen

Rozzii commented 1 month ago

/remove-lifecycle stale