-
Notifications
You must be signed in to change notification settings - Fork 277
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
Add integ tests to OpenSearch distribution build jenkins job #1517
Add integ tests to OpenSearch distribution build jenkins job #1517
Conversation
echo "buildManifestUrl (x64): ${buildManifestUrl}" | ||
|
||
String testManifest = "manifests/${TEST_MANIFEST}" | ||
if (fileExists(testManifest)) { |
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.
@dblock @peternied any other suggestion for how to handle this case? For example, plugins typically aren't on the next major version (e.g. 2.0.0), and there is no test manifest located in manifests/2.0.0
, and I'm assuming it's for this reason.
This solution just skips running the tests and adds some output explaining that no tests were ran since no test manifest was found.
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.
What about not bothering to check? If the integration tests workflow can fail because the config doesn't exist seems appropriate to me.
We avoid having problems with build manifest not existing by having them automatically generated on new version detection GitHub action, Manifest workflow. we should update that logic to add a test manifest automatically. Alternatively this might be an appropriate time to merge the input manifest and test manifests into one
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 see, so the reason there's no test manifest for 2.0.0 is because of the manual burden. And there really should be a test manifest for every input manifest. In that case I agree it makes sense to let the integ test workflow fail if no test manifest is passed.
Regarding automated test manifest generation, I'll look into it as a future PR.
echo "buildManifestUrl (x64): ${buildManifestUrl}" | ||
|
||
String testManifest = "manifests/${TEST_MANIFEST}" | ||
if (fileExists(testManifest)) { |
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.
What about not bothering to check? If the integration tests workflow can fail because the config doesn't exist seems appropriate to me.
We avoid having problems with build manifest not existing by having them automatically generated on new version detection GitHub action, Manifest workflow. we should update that logic to add a test manifest automatically. Alternatively this might be an appropriate time to merge the input manifest and test manifests into one
def inputManifest = lib.jenkins.InputManifest.new(readYaml(file: args.manifest)) | ||
def buildManifest = lib.jenkins.BuildManifest.new(readYaml(file: args.manifest)) | ||
String artifactUrl = inputManifest.getPublicDistUrl("${PUBLIC_ARTIFACT_URL}", "${JOB_NAME}", "${BUILD_NUMBER}", buildManifest.build.platform, buildManifest.build.architecture) | ||
echo "Setting env.\"ARTIFACT_URL_${buildManifest.build.platform}_${buildManifest.build.architecture}\"=${artifactUrl}" |
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.
This shouldn't be deleted, it creates the part of the build notification with instructions on where the build is located.
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.
From my understanding this isn't used by the build notifications - instead, messages are added in uploadArtifacts which is called in the build steps via buildAssembleUpload. Then, the message with the links to the manifests are added in the notification's extra
field here.
But, these env vars are still used in buildDockerImage. These can be removed though, and we could set them explicitly in the pipeline itself (we already derive the value here). Then they can be passed explicitly to buildDockerImage()
instead of relying on an env var being set. What do you think?
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.
Ah, thanks for checking in on that.
I would prefer moving to parameters to remove these 'hidden' ENV variables
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.
Totally agreed, I'll go ahead with that approach
vars/runIntegTests.groovy
Outdated
@@ -0,0 +1,14 @@ | |||
void call(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.
I'm not sure this file as indirection is very useful the amount of code to call this function is nearly the same as this file. Note; this would be more useful if it was automagically handling opensearch dashboards
FYI @tianleh
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.
Right, this script isn't doing so much now, and is really only abstracting out the job name. I'm ok to remove and add directly in distribution-build workflow.
Regarding dashboards, ideally the integ-test job won't need new parameters - runIntegTestScript (which is called in the integ-test job) is where the logic can be added to handle dashboards. It may need some additional args to handle multiple build manifests, for example.
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.
Thanks for the discussion about the support for OpenSearch Dashboards. It will need the artifact url for Dashboards from its own distribution build job (similar to the one in this PR) and one additional url for OpenSearch (which will be the latest
url). Maybe there will be some common logic for the first part. However, to avoid using if/else as branching logic, I could image that it is very possible to be two different files. I am ok to perform some refactoring once I start working on the Dashboards part (after your work is merged).
def inputManifest = lib.jenkins.InputManifest.new(readYaml(file: args.manifest)) | ||
def buildManifest = lib.jenkins.BuildManifest.new(readYaml(file: args.manifest)) | ||
String artifactUrl = inputManifest.getPublicDistUrl("${PUBLIC_ARTIFACT_URL}", "${JOB_NAME}", "${BUILD_NUMBER}", buildManifest.build.platform, buildManifest.build.architecture) | ||
echo "Setting env.\"ARTIFACT_URL_${buildManifest.build.platform}_${buildManifest.build.architecture}\"=${artifactUrl}" |
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.
Ah, thanks for checking in on that.
I would prefer moving to parameters to remove these 'hidden' ENV variables
Still investigating the instability in integ tests. Some are related to plugin-level flaky tests, others are related to the Jenkins envs. Tracking in meta issue here: #1531 I feel we shouldn't merge these changes until the integ tests become stable enough where there's not constant distribution-build failures because of this. The other option is try/catch the integ test failures for now to prevent the builds from being blocked, and remove at a later time when the tests are more stable. |
I would prefer we run these tests more and start to flush out all the different random failures. Can merge a version of this PR that does not stop the distribution jobs success notification and we get a second notification for the integ test pass/failure? |
Agreed, that's why I've opened that other issue to try to throw in all of the different errors I've seen. I think it makes sense to merge a non-blocking version for now and continue fixing the integ test failures. Regarding notifications, the integ-test job itself already publishes those results in its own job. I think we could either:
|
I'm holding off on reviewing until this switching over to |
2f52a24
to
1f297e7
Compare
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 with the remaining renames
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
cbbb989
to
bd91902
Compare
Signed-off-by: Tyler Ohlsen <[email protected]>
Signed-off-by: Tyler Ohlsen <[email protected]>
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.
Super close, just a couple changes and lets get this merged
Signed-off-by: Tyler Ohlsen <[email protected]>
…rch-project#1517) * Hook up integ tests to distribution-build Signed-off-by: Tyler Ohlsen <[email protected]> * yamlfix test manifest file Signed-off-by: Tyler Ohlsen <[email protected]> * Remove unnecessary BuildManifest fns Signed-off-by: Tyler Ohlsen <[email protected]> * Remove runIntegTests(); refactor buildDockerImage vars as params Signed-off-by: Tyler Ohlsen <[email protected]> * Comment out notification block on dashboards dist build job Signed-off-by: Tyler Ohlsen <[email protected]> * Test out stabler integ test job Signed-off-by: Tyler Ohlsen <[email protected]> * Add test pipeline for pulling nested build info Signed-off-by: Tyler Ohlsen <[email protected]> * Remove test pipeline Signed-off-by: Tyler Ohlsen <[email protected]> * Add back notifications in OSD dist build Signed-off-by: Tyler Ohlsen <[email protected]> * Remove few extra test output lines Signed-off-by: Tyler Ohlsen <[email protected]> * Clean up buildDockerImage tests Signed-off-by: Tyler Ohlsen <[email protected]> * Update params in check-for-build cron; add icon in notifications Signed-off-by: Tyler Ohlsen <[email protected]> * Simplify notification Signed-off-by: Tyler Ohlsen <[email protected]> * Change references back to prod jenkins jobs Signed-off-by: Tyler Ohlsen <[email protected]>
Description
Adds a call to an integ test groovy script which triggers the integ test jenkins job, inside of the distribution build jenkins job.
More details:
TEST_MANIFEST
parameter to the distribution-build job, needed for propagating to integ-test jobmanifest
arg used in many of the dependent groovy fns toinputManifest
orbuildManifest
to make code more readable. Makes the fn calls explicitly set the input/build manifest args rather than relying on implicit env vars (e.g., relying on an existingINPUT_MANIFEST
var to be set)PR is currently in draft. Things to do before it is ready for merging:
Playground/ohltyler-*
) to production jobsIssues Resolved
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.