-
Notifications
You must be signed in to change notification settings - Fork 558
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
UpgradeTest.upgradeWithoutSnapshot is flaky #5804
Labels
kind/flake
Categorizes issue or PR as related to a flaky test
severity/low
Marks a bug as having little to no noticeable impact for the user
Comments
korthout
added
severity/low
Marks a bug as having little to no noticeable impact for the user
Status: Needs Priority
and removed
Status: Needs Triage
labels
Nov 10, 2020
I think I know the issue, and hope I can fix it with #5385 |
8 tasks
This was referenced Nov 16, 2020
zeebe-bors bot
added a commit
that referenced
this issue
Nov 17, 2020
5855: [BACKPORT 0.25] Fix upgrade tests with and without snapshot r=npepinpe a=npepinpe ## Description This PR backports #5816 to 0.25. There was a single merge conflict where `docker-java-api` had to be added as an explicit dependency to the `parent/pom.xml` (but was already present in develop). ## Related issues related to #5385 related to #5804 backports #5816 ## Definition of Done _Not all items need to be done depending on the issue and the pull request._ Code changes: * [x] The changes are backwards compatibility with previous versions * [x] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually. Testing: * [x] There are unit/integration tests that verify all acceptance criterias of the issue * [x] New tests are written to ensure backwards compatibility with further versions * [x] The behavior is tested manually * [ ] The impact of the changes is verified by a benchmark Documentation: * [ ] The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.) * [ ] New content is added to the [release announcement](https://drive.google.com/drive/u/0/folders/1DTIeswnEEq-NggJ25rm2BsDjcCQpDape) Co-authored-by: Nicolas Pépin-Perreault <nicolas.pepin-perreault@camunda.com>
zeebe-bors bot
added a commit
that referenced
this issue
Nov 17, 2020
5856: [BACKPORT 0.24] Fix upgrade tests with and without snapshot r=npepinpe a=npepinpe ## Description This PR backports #5816 to 0.24. There were some merge conflicts in `update-tests`, related to `ContainerState`, please have a second look. I also bumped the `backwards.compat.version` which the new `update-compat-java` release script would also do now. ## Related issues related to #5385 related to #5804 backports #5816 ## Definition of Done _Not all items need to be done depending on the issue and the pull request._ Code changes: * [x] The changes are backwards compatibility with previous versions * [x] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually. Testing: * [x] There are unit/integration tests that verify all acceptance criterias of the issue * [x] New tests are written to ensure backwards compatibility with further versions * [x] The behavior is tested manually * [ ] The impact of the changes is verified by a benchmark Documentation: * [ ] The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.) * [ ] New content is added to the [release announcement](https://drive.google.com/drive/u/0/folders/1DTIeswnEEq-NggJ25rm2BsDjcCQpDape) Co-authored-by: Nicolas Pépin-Perreault <nicolas.pepin-perreault@camunda.com>
zeebe-bors bot
added a commit
that referenced
this issue
Nov 17, 2020
5856: [BACKPORT 0.24] Fix upgrade tests with and without snapshot r=npepinpe a=npepinpe ## Description This PR backports #5816 to 0.24. There were some merge conflicts in `update-tests`, related to `ContainerState`, please have a second look. I also bumped the `backwards.compat.version` which the new `update-compat-java` release script would also do now. ## Related issues related to #5385 related to #5804 backports #5816 ## Definition of Done _Not all items need to be done depending on the issue and the pull request._ Code changes: * [x] The changes are backwards compatibility with previous versions * [x] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually. Testing: * [x] There are unit/integration tests that verify all acceptance criterias of the issue * [x] New tests are written to ensure backwards compatibility with further versions * [x] The behavior is tested manually * [ ] The impact of the changes is verified by a benchmark Documentation: * [ ] The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.) * [ ] New content is added to the [release announcement](https://drive.google.com/drive/u/0/folders/1DTIeswnEEq-NggJ25rm2BsDjcCQpDape) Co-authored-by: Nicolas Pépin-Perreault <nicolas.pepin-perreault@camunda.com>
zeebe-bors bot
added a commit
that referenced
this issue
Nov 18, 2020
5856: [BACKPORT 0.24] Fix upgrade tests with and without snapshot r=npepinpe a=npepinpe ## Description This PR backports #5816 to 0.24. There were some merge conflicts in `update-tests`, related to `ContainerState`, please have a second look. I also bumped the `backwards.compat.version` which the new `update-compat-java` release script would also do now. ## Related issues related to #5385 related to #5804 backports #5816 ## Definition of Done _Not all items need to be done depending on the issue and the pull request._ Code changes: * [x] The changes are backwards compatibility with previous versions * [x] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually. Testing: * [x] There are unit/integration tests that verify all acceptance criterias of the issue * [x] New tests are written to ensure backwards compatibility with further versions * [x] The behavior is tested manually * [ ] The impact of the changes is verified by a benchmark Documentation: * [ ] The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.) * [ ] New content is added to the [release announcement](https://drive.google.com/drive/u/0/folders/1DTIeswnEEq-NggJ25rm2BsDjcCQpDape) Co-authored-by: Nicolas Pépin-Perreault <nicolas.pepin-perreault@camunda.com>
test was renamed to Stacktrace:
|
Prioritized as high as it's currently failing the builds often. |
Should wait until #5872 is merged so we also get the container logs. |
8 tasks
zeebe-bors bot
added a commit
that referenced
this issue
Nov 23, 2020
5897: Improve reliability of UpdateTest suite r=MiguelPires a=npepinpe ## Description This PR aims to improve the reliability of the `UpdateTest` suite by dropping the use of `TestUtil` in favour of `Awaitility`. I believe it will help as `TestUtil` is retry based - it will retry up to X amount of times, and fail. If your callable is fast, then this means it may wait for a very short amount of time before stopping. If you look at the past failures, this is essentially what was happening - we weren't waiting long enough for the logs to be printed out and consumed. Switching to Awaitility improves on this by allowing us to specify a time out, how often the callable should be called, and also helps provide more context when it fails (`TestUtil` essentially returns "true" or "false"). ## Related issues closes #5804 closes #5894 ## Definition of Done _Not all items need to be done depending on the issue and the pull request._ Code changes: * [x] The changes are backwards compatibility with previous versions * [x] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually. Testing: * [x] There are unit/integration tests that verify all acceptance criterias of the issue * [ ] New tests are written to ensure backwards compatibility with further versions * [x] The behavior is tested manually * [ ] The impact of the changes is verified by a benchmark Documentation: * [ ] The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.) * [ ] New content is added to the [release announcement](https://drive.google.com/drive/u/0/folders/1DTIeswnEEq-NggJ25rm2BsDjcCQpDape) Co-authored-by: Nicolas Pépin-Perreault <nicolas.pepin-perreault@camunda.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
kind/flake
Categorizes issue or PR as related to a flaky test
severity/low
Marks a bug as having little to no noticeable impact for the user
Summary
UpgradeTest.upgradeWithoutSnapshot failed and then completed successfully. It failed because a workflow instance was not completed in time. https://ci.zeebe.camunda.cloud/blue/organizations/jenkins/zeebe-io%2Fzeebe/detail/staging/2472/
Failures
Example assertion failure
Hypotheses
Perhaps not enough resources to complete the wfi in time.
Logs
Logs
The text was updated successfully, but these errors were encountered: