-
Notifications
You must be signed in to change notification settings - Fork 4
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 all relevant tests on all PRs #148
Conversation
The github workflow files are generated from templates in
Does that mean we don't expect all the tests to be running on this branch since it's called |
For the previous release logic:
Would we expect that to be v15.0.3-shopify-10? For the next release logic:
Should that have been either |
Updated to use the templates
Yes, it should be skipping tests in this branch. Gonna look at why it ended up trying to run some of the tests |
I think that makes sense to fallback to an upstream release if a shopify release doesn't exist yet. I've updated the script to do that. |
46643b7
to
008b78f
Compare
Would it make sense to never skip tests? It might be nice to have tests running on prototype branches and it would mean we wouldn't need to be careful about always opening PRs from |
4a49f76
to
07b1add
Compare
Then we might need a different way of identifying which version a PR is going to merge to. Currently, the version specified in the branch name is used to figure out the versions for the upgrade/downgrade tests. If, for example, we have a |
Presumably the source and target branch of a PR both have the same major version, so maybe we could pull the version from here? https://github.com/Shopify/vitess/blob/main/go/vt/servenv/version.go#L22 |
Made some changes:
|
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 this. Two comments (apart from the sort usage):
-
Should we move the
_shopify
scripts to a/shopify
sub directory instead of using the suffix as the name? -
Would be great if there were some tophatting instructions, with e.g. what would the expected output of the two scripts be if we were checked out on a given version. For now I have:
HEAD | previous_release | next_release |
---|---|---|
fix-tests | v15.0.3-shopify-10 | v17.0.5 |
v15.0.3-shopify-10 | v | v16.0.7 |
The "previous" value for v15.0.3-shopify-10 looks suspicious but I suspect it's because we were not following the tag hygiene previous to v15. (I don't see any such tags for v14 for example). Seems fine? But would appreciate tallying with an expected table.
tools/get_next_release_shopify.sh
Outdated
|
||
target_release="" | ||
|
||
latest_major_release=$(git show-ref | grep -E 'refs/remotes/origin/v[0-9]*.[0-9]*.[0-9]*-shopify-[0-9]*$' | sed 's/[a-z0-9]* refs\/remotes\/origin\/v//' | sed 's/\.0//' | sort -nr | head -n1) |
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's a bit unclear to me what major_release
means here. Is it just the 16
part of 16.0.7-shopify-1
for example? Or is it 16.0.7-shopify-1
in its entirety?
Also should we do sort -Vr
instead? Currently it sorts *-shopify-10
after *-shopify-9
.
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.
major_release is the 16
in 16.0.7-shopify-1
. I think it makes more sense to look at latest major releases from upstream instead of shopify releases so I've updated that.
Essentially, it's used to compare with the major version that the PR is merging unto. If it's the same, then it uses the main branch to do the upgrade tests.
Having it only look at Shopify releases might lead to picking incorrect versions since if our latest release is, for example, v18
and we make a patch for v18
, it would incorrectly pick main
to compare with (instead of v19
)
That's a good call. I'll post some 🎩 instructions |
🎩 instructions
The empty string in previous releases is expected since we don't have any shopify releases that would match. This is okay because whenever we make a patch from now on, we will be guaranteed to have a previous shopify release. |
tools/get_next_release_shopify.sh
Outdated
|
||
target_release="" | ||
|
||
latest_major_release=$(git show-ref | grep -E 'refs/remotes/origin/release-[0-9]*\.0$' | sed 's/[a-z0-9]* refs\/remotes\/origin\/release-//' | sed 's/\.0//' | sort -Vr | head -n1) |
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.
Was just testing this after pushing the latest v19.0.0 release tag (see https://github.com/Shopify/vitess-build/pull/58). This line is returning 18, not 19, because it's looking for release branches in our repo (which would need to be manually synced each time a new one is created upstream). Maybe this should look at tags instead?
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 figured we sync major release branches into our repo since I saw the other releases but if that's not usually the case, makes sense to look at tags instead.
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.
🎉
b55dd26
into
v16.0.7-shopify-1-candidate
Run all relevant tests on all PRs (cherry picked from commit b55dd26)
run make generate_ci_workflows similar to #148 remove custome machines for runs-on run make generate_ci_workflows use ubuntu
Fixes https://github.com/Shopify/vitess-project/issues/613
This PR:
-shopify
release on the previous major release.-shopify
release on the next major release, falling back to an upstream release if a shopify release doesn't exist.go/vt/servenv/version.go
to get the current version that a PR is making a fix to.skip-workflow
logic so that we don't skip tests in PRs🎩 instructions
go/vt/servenv/version.go
and updateversionName
to the value inversion.go
below../tools/get_next_release_shopify.sh
and./tools/get_previous_release_shopify.sh
The empty string in previous releases is expected since we don't have any shopify releases that would match. This is okay because whenever we make a patch from now on, we will be guaranteed to have a previous shopify release.