You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On merge into main (or part of the manual release process?), we should have a GitHub action that will:
create a kube cluster
clone/download and run the previous latest release of FTL
deploy the exemplar
run the exemplar's smoke test (?)
upgrade FTL to the latest main
run the exemplar's smoke test
re-deploy the latest exemplar
re-run the smoke tests
If this is run on merges to main, we'll have to figure out a way to be notified of failures. If it's run as part of the manual release process, failures should block the release.
The text was updated successfully, but these errors were encountered:
There is nothing in there about upgrades but I don't think it would be that much work. It's not quite the same as running on a 'real' cluster but is a lot lighter weight in terms of providing a smoke test.
Smoke testing the upgrade path from the last FTL release is a bit of a chicken and egg, especially for the first upgrade test, but also because the smoke tests themselves can be updated. We also can't just grab the latest smoke test, since it may refer to newly added FTL features / test cases in the exemplar. My current thinking is to:
clone the FTL repo at the last tagged release
run that release's smoke tests on that release's exemplar (what if it doesn't have it?)
clone the FTL repo at the current HEAD
upgrade FTL without redeploying the exemplar modules (is this possible?)
run the previous smoke tests on that release's exemplar
For (2), we skip since we can't test upgrade and the integration test will cover the non-upgrade path.
For (4), seems like the GHA will need to deploy the modules separately from running the smoke test on them, so that it can upgrade FTL and skip the deploy part.
For (5), we need to check out the latest HEAD but the latest tagged release's smoketest directory.
The above tests that a new release is still compatible with old modules, but it doesn't test the upgrade path the way FTL client projects would upgrade. We'll need to use the long-living FTL cluster for that.
On merge into main (or part of the manual release process?), we should have a GitHub action that will:
If this is run on merges to main, we'll have to figure out a way to be notified of failures. If it's run as part of the manual release process, failures should block the release.
The text was updated successfully, but these errors were encountered: