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

Server logs should be written when integration tests fail #4804

Merged
merged 2 commits into from
Nov 13, 2023

Conversation

niloc132
Copy link
Member

@niloc132 niloc132 commented Nov 9, 2023

Fixes #4766

Copy link
Member

@devinrsmith devinrsmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to dig in a bit more - posted initial thoughts.

Comment on lines +367 to +368
// Specify that makeImage is finalized by buildAndRun - that is, in this configuration buildAndRun
// must run after makeImage finishes
Copy link
Member

@devinrsmith devinrsmith Nov 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your comment buildAndRun must run after makeImage is a bit at odds with the typical gradle terminology. I'm digging in now; I don't know if finalizedBy is the technically correct solution here (it may very well be...).

https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:finalizer_tasks

Finalizer tasks are useful in situations where the build creates a resource that has to be cleaned up regardless of the build failing or succeeding.

https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:ordering_tasks

When you use the “must run after” ordering rule you specify that taskB must always run after taskA, whenever both taskA and taskB will be run. This is expressed as taskB.mustRunAfter(taskA).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mustRunAfter/shouldRunAfter only sets an ordering requirement, but does not mandate that the earlier or later task run at all, they can run or not run independently.

On the other hand, b.dependsOn(a) means that if b is requested to run, a must run first and must be successful, whereas a.finalizedBy(b) means that if a will run, b must run afterwards (regardless of whether or not a is successful).

onlyIf { buildAndRun.get().state.failure != null }
doLast {
if (buildAndRun.get().state.failure != null) {
throw new GradleException('Docker task failed, see earlier task failures for details')
Copy link
Member

@devinrsmith devinrsmith Nov 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might add a comment this isn't an illegal state, we just want to preserve / propagate the failure, correct? I wonder if we should have a separate task that propagates this failure, instead of attaching it to the Sync task? (which may have specific semantics attached to sync-related failures.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct - not an illegal state (and the choice of GradleException is I thought intended to convey that), but just a failure. If this task did not throw an exception (or otherwise fail), it wouldn't be clear to other tasks that they should/shouldn't continue (e.g. "if it failed, dont continue to build downstream artifacts" vs "if it failed, make sure we dump the server's logs").

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note also that a new task with actions (i.e. "fail if that other thing failed") but no inputs or outputs can never be up to date. I'm not aware of Sync specific errors, but can add a comment here to call out what is going on, besides the wall of text written at the top of this section.

jcferretti
jcferretti previously approved these changes Nov 13, 2023
devinrsmith
devinrsmith previously approved these changes Nov 13, 2023
@niloc132 niloc132 enabled auto-merge (squash) November 13, 2023 20:38
@niloc132 niloc132 merged commit a61a8ef into deephaven:main Nov 13, 2023
9 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Nov 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Server logs not written out after go:testGoClientRun failure
3 participants