Get tsdb version from version.config if run from a tag - #10023
Conversation
|
After this we should fix that the spawned tests after the release is released is run from the tag and not main (as it happens right now), additionally it might make sense to add some delay, e.g. 4-5minutes, as packagecloud will also need a few seconds to properly index and serve the new binaries |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
| version=$(wget -q https://api.github.com/repos/timescale/timescaledb/releases/latest -O - | jq -r .tag_name) | ||
| # if run from a tag, check the repo's version, meant to be run after a release | ||
| # otherwise we rely on github's api for scheduled runs. | ||
| if [ "${{ github.ref_type }}" = "tag" ]; then |
There was a problem hiding this comment.
This test is supposed to check the version of packages in the package repo, right? It's expected that it fails if the version of packages is not up to date.
I think it will lead to confusion if it actually doesn't check it sometimes, depending on the run conditions.
There was a problem hiding this comment.
It is expected to fail if the repo's version does not match the latest installable version, when run from a tag, which we only do after releases.
The way I see it is that we currently miss some test surface, e.g. in the last release it didn't catch that the binaries were actually not uploaded, with this it'd have caught it.
To make it less confusing we could add logging explaining why it failed, but we need to run this test.
There was a problem hiding this comment.
Could also create a different step and conditionally run it, same logic just on the github step level
|
This pull request has been automatically marked as stale due to lack of activity. This pull request will be closed in 30 days. |
2 participants
After running a package test (apt in this case) after a release, we take the latest available version and compare it to the latest installable versions, the version is obtained from Github's API, which can take 2-3 minutes sometimes, so a stale version can false-positive several situations, for example if the packages dont get uploaded to cloud, as in the 2.27.2 release it'd compare the stale github version e.g. 2.27.1 with the latest available installable version, 2.27.1, making the test pass in the 2.27.2 branch.
With this fix we take the version from the repo
version.configwhen the run is from a tab, e.g. after a release, so cases like this are caught in the CI. If normally run, e.g. scheduled run, the behaviour is unchanged.