-
Notifications
You must be signed in to change notification settings - Fork 42
[CI] tear down the workspace #885
[CI] tear down the workspace #885
Conversation
/** | ||
* Tear down the setup for the static workers. | ||
*/ | ||
def tearDown(Map args = [:]){ |
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.
Wdyt about having a specific step in the library for cleaning up Go dependencies?
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.
IMO the build system should be the one ensuring the workspace is in good shape. Then the CI should only caring to delete the workspace if required.
Though, it seems go
has got some opinionated approach and the build system does not provide those tools, based on that, we could create a specific step in the library to help with.
There are some questions regarding:
- the new step will always run within the
Go
environmental context? - if running as a post declarative step, will it work?
Do you think we just need to raise an issue regarding this improvement?
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 was/am concerned about having the very same method in different pipelines (Beats and here) and probably in many of the other Go projects that we maintain.
I agree that the build system should keep the workspace and dependencies in a good shape, but as you know there is nothing as maven/gradle to do so.
Regarding your questions:
- I think the Go environment should be the same, just in case the
clean
method could change between different Go versions - I've been reading about
go clean
. Do you think it could be a best practice to invoke it before tests run? The same we domvn clean test
in the Maven world. If so then we should not think about the post step issue, as the environment would always be right. Even better, we could enforce the clean in the set Go env step 🤔
💔 Tests Failed
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪Test errorsExpand to view the tests failures
|
BTW, the step in the pipeline shows this message:
Is it related? |
It's now much better with 4630b71 |
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.
LGTM! The failed test seems one of the flaky ones
error(e.toString()) | ||
} finally { | ||
junit(allowEmptyResults: true, keepLongStdio: true, testResults: "${BASE_DIR}/outputs/TEST-*.xml") | ||
} finally { |
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.
We only need the finally, then error is redundant
…hings * upstream/master: [CI] tear down the workspace (elastic#885) docs: add Make as build system (elastic#886) fix: proper usage of step (elastic#883) feat: run most frequent flavours in the PR stage (elastic#873) break: move from "pull-requests" to "commits" GCP bucket (elastic#866) fix: use proper flags (elastic#868) feat: instrument Helm charts test suite (elastic#858)
What does this PR do?
Delete workspace
Why is it important?
If we use static/permanent workers then we might suffer disk space issues
Checklist
make notice
in the proper directory)Author's Checklist
How to test this PR locally
Related issues
Closes #884
#707 can benefit from this :)