-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
upgrades: upgrades don't seem to run when developmentBranch
is set to false
#100685
Comments
3 tests that fail in #99387 are: (1)
(2)
(3)
|
cockroach/pkg/ccl/serverccl/server_startup_guardrails_test.go Lines 33 to 35 in ff2c4a3
|
@renatolabs any suggestion as to how to achieve what the test wants to exercise, instead? |
Since that test already relies on version keys to pass a custom |
Yes I would love that ❇️ |
When overwriting versions for that test, we were unconditionally applying `clusterversion.DevOffset` to all versions. While that works on master, it makes the test break when it runs on a release branch (where no offsetting happens). In this commit, we check whether binary versions are offset, and only add the DevOffset if they are. Unfortunately, we can't reference versions by key in this test as it references versions from two releases ago. Informs: cockroachdb#100685 Epic: none Release note: None
98240: release: split release process r=jlinder a=rail Previously, the release publishing step contained building, signing and other operations that can happen in advance. This PR splits the release process into 2 steps: build/sign and publishing. Artifacts generated during the build stage are published to a "staged" bucket and copied to the final bucket during the publishing phase. * Extracted docker verification into a function. * The version is read from a file now. * Use `gsutil` in MacOS signing in order to download from private repos. * Removed `PRE_RELEASE` variable set from TeamCity in favour of "guessing" it from the version. * Simplified dry-run logic to define version/build names, because the version is defined in the source code now. * The publishing phase updates docker image packages. Epic: RE-307 Fixes: RE-211 Release note: None 100641: upgrades: update helper fn ExecForCountInTxns to retry transactions r=rafiss a=andyyang890 This patch updates the ExecForCountInTxns helper function to retry transactions to prevent spurious test failures. Fixes: #100158 Release note: None 100657: builtins: remove crdb_internal.no_constant_folding builtin r=yuzefovich a=yuzefovich This function no longer does what it's intended to do (namely disabling the constant folding of the whole expression, for testing purposes) because it was only supported in the heuristics planner. This builtin is also not used anywhere in our tests. Epic: None Release note: None 100700: kvtenantccl: unskip TestTenantUpgrade r=rafiss a=nicktrav This test was skipped as part of #97076. Re-enable the test. Fix #97076. Release note: None. 100701: serverccl: conditionally apply DevOffset in TestServerStartupGuardrails r=knz a=renatolabs When overwriting versions for that test, we were unconditionally applying `clusterversion.DevOffset` to all versions. While that works on master, it makes the test break when it runs on a release branch (where no offsetting happens). In this commit, we check whether binary versions are offset, and only add the DevOffset if they are. Unfortunately, we can't reference versions by key in this test as it references versions from two releases ago. Informs: #100685 Epic: none Release note: None Co-authored-by: Rail Aliiev <[email protected]> Co-authored-by: Andy Yang <[email protected]> Co-authored-by: Yahor Yuzefovich <[email protected]> Co-authored-by: Nick Travers <[email protected]> Co-authored-by: Renato Costa <[email protected]>
When overwriting versions for that test, we were unconditionally applying `clusterversion.DevOffset` to all versions. While that works on master, it makes the test break when it runs on a release branch (where no offsetting happens). In this commit, we check whether binary versions are offset, and only add the DevOffset if they are. Unfortunately, we can't reference versions by key in this test as it references versions from two releases ago. Informs: #100685 Epic: none Release note: None
I'm not sure if this has already been identified, but setting @adityamaru any ideas on this failure? |
@renatolabs I'll spend some time understanding what developmentBranch has to do with the failure but applying this diff seems to fix the test. We don't expect
|
99288: cdc: add apache arrow parquet library and writer r=miretskiy a=jayshrivastava #### cdc: add apache arrow parquet library This commit installs the apache arrow parquet library for Go at version 11. The release can be found here: https://github.com/apache/arrow/releases/tag/go%2Fv11.0.0 This library is licensed under the Apache License 2.0. Informs: #99028 Epic: None Release note: None --- #### util/parquet: create parquet writer library This change implements a `Writer` struct in the new `util/parquet` package. This `Writer` writes datums to the `io.Writer` sink using a configurable parquet version (defaults to v2.6). The package implements several features internally required to write in the parquet format: - schema creation - row group / column page management - encoding/decoding of CRDB datums to parquet datums Currently, the writer only supports types found in the TPCC workload, namely INT, DECIMAL, STRING UUID, TIMESTAMP and BOOL. This change also adds a benchmark and tests which verify the correctness of the writer and test utils for reading datums from parquet files. Informs: #99028 Epic: None Release note: None --- #### changefeedccl: add parquet writer This change adds the file `parquet.go` which contains helper functions to help create parquet writers and export data via `cdcevent.Row` structs. This change also adds tests to ensure rows are written to parquet files correctly. Epic: None Release note: None 100830: upgrademanager: fix upgrade manager tests that relied on wrong invariants r=knz a=adityamaru The two tests in question were low level tests that upgrade clusters from mock version 41 to 42 and override the upgrade flow to test the internals of the upgrade manager. These mock cluster versions were not tied to our real cluster versions and so were not offset with the `DevOffset` when a branch is marked as a development branch. For this reason when a branch was a developmentBranch they would sort under all the "real" cluster versions while when a branch was marked as a release branch they would sort above all the "real" cluster versions. This undeterministic behaviour did not play well with certain job migrations that were added this release. This change rewrites the test to use real cluster versions so that their values are in sync with whether the branch is a developmentBranch or not. This change also removes some overrides to make the test more intuitive. Cocnretely, the test servers now bootstrap at the minimum supported binary version and run all the upgrades until the `startCV` before executing the body of the test. Fixes: #100685 Informs: #100552 Release note: None Co-authored-by: Jayant Shrivastava <[email protected]> Co-authored-by: adityamaru <[email protected]>
…ants The two tests in question were low level tests that upgrade clusters from mock version 41 to 42 and override the upgrade flow to test the internals of the upgrade manager. These mock cluster versions were not tied to our real cluster versions and so were not offset with the `DevOffset` when a branch is marked as a development branch. For this reason when a branch was a developmentBranch they would sort under all the "real" cluster versions while when a branch was marked as a release branch they would sort above all the "real" cluster versions. This undeterministic behaviour did not play well with certain job migrations that were added this release. This change rewrites the test to use real cluster versions so that their values are in sync with whether the branch is a developmentBranch or not. This change also removes some overrides to make the test more intuitive. Cocnretely, the test servers now bootstrap at the minimum supported binary version and run all the upgrades until the `startCV` before executing the body of the test. Fixes: #100685 Informs: #100552 Release note: None
reopening until the backport is merged |
backport has been merged! |
Thank you, all! 🙌🏼 |
When manually modifying
developmentBranch
(as in #99387) a couple of tests[1] fail.For example:
This suggests that we are not properly running the SQL migrations in that case.
[1] Tests that fail:
Jira issue: CRDB-26555
The text was updated successfully, but these errors were encountered: