-
Notifications
You must be signed in to change notification settings - Fork 13
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
Run tests with spin-registry-push as well #90
Conversation
f8e0b07
to
45ffa8a
Compare
requesting review from @kate-goldenring @Mossaka @jsturtevant @vdice |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me! Excited to have these tests in place 🚀
Makefile
Outdated
|
||
.PHONY: integration-docker-build-push-tests | ||
integration-docker-build-push-tests: workloads | ||
cargo test -p containerd-shim-spin-tests -- --nocapture |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this cargo test command fails, will the cleanup commands below still run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will fail currently. do you think that is a fair outcome or you would expect it to fail these tests and run the other set of tests (spin-registry-push testcases)
given we are using same k3d cluster to run both tests right now, i think if it fails, we should fail the complete job. As suggested in one of the other comment on this PR, we should do a follow up PR to separate these two tasks as separate steps in CI workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm in support of failing the complete job if this task fails. I was more worried about lingering resources when this cargo test ...
command fails and so the subsequent kubectl delete ...
cleanup commands don't run. I suppose in CI it doesn't matter... but maybe in dev scenarios?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @vdice, how do you suggest we handle this? one way would be to capture the output and exit code and then throw a new error after cleanup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this logic is now in a shell script. I'd say let's not worry about it for this PR and we can add a follow-up if we run into this scenario when developing/running tests locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 , i moved it to shell script in response to other comments around unifying some of the scripts. agree that we can work on a separate PR to improve this further.
|
||
set -euo pipefail | ||
|
||
# Check if kubectl is installed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit/potential follow-up: Would be nice to consolidate all of the logic shared by these two scripts. Looks like everything is the same besides the kubectl apply -f tests/workloads-{spin-registry-push | docker-build-push}
bit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree. I didn't want to touch a lot of existing scripts in this PR to avoid breaking workflow other folks are used to when testing changes and to keep the changes contained for easy review.
I can take up another task next to cleanup the scripts a bit and try out dagger functions to see if they help simplify our workflows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to @vdice 's comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would we be fine to add a param to this script to tell which one we want to run now.
e.g. it would become something like:
./workloads.sh "spin-registry-push-artifacts"
and
./workloads.sh "docker-build-push-artifacts"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've taken a stab at restructuring this a bit as suggested.
- renamed
workloads.sh
todeploy-workloads.sh
- this by default deploysdocker build
artifacts, but we can pass a command line argument to deployspin registry push
artifacts - renamed
workloads-delete.sh
topod-terminates-test.sh
to reflect the actual purpose of that script - added
teardown-workloads.sh
to delete all the workloads deployed bydeploy-workloads.sh
Kindly let me know if this looks any better. happy to hear more feedback and adjust accordingly. kindly let me know (and thank you for spending time to review the code with me here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank's @rajatjindal! Just had a few cleanup oriented nits
tests/workloads-spin-registry-push/workload-spin-registry-push.yaml
Outdated
Show resolved
Hide resolved
tests/workloads-spin-registry-push/workload-spin-registry-push.yaml
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, one future improvement might be to separate the different tests into distinct tasks in the CI job.
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
45ffa8a
to
c60922a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on improving the integration tests!
I'd suggest to consolidate two different integration paths into one set of workloads. Perhaps, we can create two services and have one ingress loadbalancer to route traffic to either docker-push
or spin-registry-push
sudo rustup target add wasm32-wasi && sudo rustup target add wasm32-unknown-unknown | ||
|
||
## setup tinygo. required for building test spin app | ||
echo "setting up tinygo" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is TinyGo needed? I thought Spin apps are built through Dockerfile which already has TinyGo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @Mossaka, we need tinygo for building this app: https://github.com/spinkube/containerd-shim-spin/tree/main/images/spin/go-hello
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are using Docker to build images and the Dockerfile in images/spin
will install TinyGo. Am I missing anything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh apologies for the confusion.
Now that we need to run tests with "spin registry push" version as well, we push the apps in following two ways:
docker build && k3d import image
(was already part ofup.sh
)spin build && spin registry push <artifact>
(added toup.sh
). This runs on the runner machine, and therefore needs tinygo installed.
does that answer your question?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, that makes sense. Maybe as follow-up I wonder if we could run docker build
and then extract the component binary out and use it as the artifact for spin registry push
. (this will reduce the amount of deps we need to install on the host machine).
|
||
set -euo pipefail | ||
|
||
# Check if kubectl is installed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to @vdice 's comment
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
0ffb3b3
to
972e6e3
Compare
Hi @Mossaka, when you have some bandwidth, could you please (re)-review this PR and provide your feedback. thank you |
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
972e6e3
to
14338b4
Compare
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
sudo rustup target add wasm32-wasi && sudo rustup target add wasm32-unknown-unknown | ||
|
||
## setup tinygo. required for building test spin app | ||
echo "setting up tinygo" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah right, that makes sense. Maybe as follow-up I wonder if we could run docker build
and then extract the component binary out and use it as the artifact for spin registry push
. (this will reduce the amount of deps we need to install on the host machine).
Hi @Mossaka, could we please merge this PR (if there are no blocking comments). |
This PR adds ability to run existing tests with apps pushed using spin-registry-push command. To test that, it starts a registry, managed by k3d and build/push apps to this registry.