chore: Add pre-release PR template to run and update nightly demos #64
Conversation
There was a problem hiding this comment.
There probably needs to be another list for things to check during the demos.
- Check that the correct images are being used
# Ensure correct product versions are used as well as 0.0.0-dev kubectl get pods -n default -o yaml | yq -y '.items[] | .status.containerStatuses[] | .image' # Ensure the 0.0.0-dev operators are used. kubectl get pods -n stackable-operators -o yaml | yq -y '.items[] | .status.containerStatuses[] | .image'
- Check the demo (duh)
There was a problem hiding this comment.
For the release upgrade testing, we would modify it to ensure that the correct product versions are used, and the SDP X.XX version is used (not 0.0.0-dev).
On top of that, I think the demo should be run (according to the docs), and then the upgrade should be done. This mimics a real upgrade where there was data.
| > 1. Create a `.env` file in your local copy of this repository. | ||
| > 2. Create local stack and demo definition files, like `stacks-v2.local.yaml` | ||
| > and `demos-v2.local.yaml`. They should use the nightly version instead of | ||
| > stable. They also might need to point to local manifests instead of remote | ||
| > ones. | ||
| > 3. Add the `STACKABLE_STACK_FILES` and `STACKABLE_DEMO_FILES` env vars to the | ||
| > file. They should point to the absolute path of your local stack and demo | ||
| > definition files. |
There was a problem hiding this comment.
Just adding a different perspective to consider...
Tbh, I prefer using the checked out stack files explicitly on the command line.
The same changes get made, as you described, but if there are actual fixes needed, it is a matter of editing the same files and only checking in those changes (and reverting the other ones that get it working with nightly).
Not at all suggesting my way is better, but for me, doing the above, I would forget to unset the variable, or I would run a new shell that doesn't have it set, and invalidate the testing). I use the shell history heavily.
|
This template is a partial duplicate of the one added in stackabletech/issues#609 and modified in stackabletech/issues#602 We will consolidate them later. |
Part of stackabletech/issues#602