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

Smoke test the FTL upgrade path #2966

Open
Tracked by #2445
safeer opened this issue Oct 3, 2024 · 3 comments
Open
Tracked by #2445

Smoke test the FTL upgrade path #2966

safeer opened this issue Oct 3, 2024 · 3 comments
Assignees
Labels
codebase-health Codebase health

Comments

@safeer
Copy link
Contributor

safeer commented Oct 3, 2024

On merge into main (or part of the manual release process?), we should have a GitHub action that will:

  1. create a kube cluster
  2. clone/download and run the previous latest release of FTL
  3. deploy the exemplar
  4. run the exemplar's smoke test (?)
  5. upgrade FTL to the latest main
  6. run the exemplar's smoke test
  7. re-deploy the latest exemplar
  8. 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.

@stuartwdouglas
Copy link
Collaborator

You can probably do something like this using a similar approach to the existing kube test:

func TestKubeScaling(t *testing.T) {

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.

@safeer
Copy link
Contributor Author

safeer commented Oct 4, 2024

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:

  1. clone the FTL repo at the last tagged release
  2. run that release's smoke tests on that release's exemplar (what if it doesn't have it?)
  3. clone the FTL repo at the current HEAD
  4. upgrade FTL without redeploying the exemplar modules (is this possible?)
  5. 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.

@safeer
Copy link
Contributor Author

safeer commented Oct 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codebase-health Codebase health
Projects
None yet
Development

No branches or pull requests

2 participants