-
Notifications
You must be signed in to change notification settings - Fork 273
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
Implement a basic Jenkins job for running OpenSearch Dashboards integ test #1368
Conversation
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Codecov Report
@@ Coverage Diff @@
## main #1368 +/- ##
============================================
+ Coverage 93.94% 94.02% +0.07%
Complexity 11 11
============================================
Files 136 138 +2
Lines 2974 3013 +39
Branches 8 8
============================================
+ Hits 2794 2833 +39
Misses 172 172
Partials 8 8
Continue to review full report at Codecov.
|
@@ -0,0 +1,83 @@ | |||
lib = library(identifier: 'jenkins@20211123', retriever: legacySCM(scm)) |
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 is this identifier, why use fixed date value?
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.
Jenkins caches the library sometimes, so when we make code changes we tend to increment this everywhere.
node('Jenkins-Agent-al2-x64-c54xlarge-Docker-Host') { | ||
script { | ||
postCleanup() | ||
} | ||
} |
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.
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.
Could always cover?
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 wasn't able to extract the whole post
part with tests.
jenkins/opensearch-dashboards/integ-test-opensearch-dashboards.jenkinsfile
Outdated
Show resolved
Hide resolved
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Signed-off-by: Tianle Huang <[email protected]>
Please help take a look again when available @dblock @peternied |
Created a Github issue to support arm64 #1381 |
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.
Paths are still being computed, take a full path to as input, its simple and lets the caller have control to execute any kind of combination of sources they see fit
When I consider the functionality I think the job parameters at most need to be the following:
- the path to the test manifest file, relative position in the OpenSearch-Build repository
- the path to the opensearch distribution manifest file
- the path to the opensearch-dashboards distribution manifest file
Any other values can be inferred from those files after they've been inspected. If there is more information that is needed then we should see about putting it in the test manifest file as that should describe how to execute the tests.
version: opensearch_dashboards_version | ||
) | ||
|
||
sh "./test.sh integ-test manifests/${opensearch_dashboards_version}/opensearch-dashboards-${opensearch_dashboards_version}-test.yml -p opensearch=${basePathOpenSearch} opensearch-dashboards=${basePathOpenSearchDashboards} --test-run-id ${env.BUILD_NUMBER}" |
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.
Lets just pass the test manifest path, this is forward compatible with path changes
sh "./test.sh integ-test manifests/${opensearch_dashboards_version}/opensearch-dashboards-${opensearch_dashboards_version}-test.yml -p opensearch=${basePathOpenSearch} opensearch-dashboards=${basePathOpenSearchDashboards} --test-run-id ${env.BUILD_NUMBER}" | |
sh "./test.sh integ-test ${TEST-MANIFEST} -p opensearch=${basePathOpenSearch} opensearch-dashboards=${basePathOpenSearchDashboards} --test-run-id ${env.BUILD_NUMBER}" |
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.
Let's add test cases for both the files that added -
vars/getPublicUrl.groovy
jenkins/opensearch-dashboards/integ-test-opensearch-dashboards.jenkinsfile
name: 'platform', | ||
description: 'Platform of the build of OpenSearch/OpenSearch Dashboards', | ||
trim: true | ||
) |
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 would prefer if the parameters to this job was 1) an OpenSearch Dashboards build URL (e.g. ci.opensearch....) that contains a manifest that would get loaded and all these features such as build ID and architecture and platform were to be extracted, and 2) an OpenSearch URL. Otherwise we keep building assumptions in the URL structure of where things are built, ie. this job "knows" something it shouldn't about the location of builds. Then this code loads the manifest(s) and has everything it needs, it would be shorter and easier to grok.
Use CAPS for variables similarly to other Jenkinsfile.
will work on this issue #1482 first so that the release url has the same substructure similar to regular distribution url |
Tried to add builds/dist in #1490 However, we may need an alternative approach. |
Need to complete this pre-requested issue first #1492 |
This work is switched to #1653 |
Description
It sets up the basic structure as incremental progress including the input parameters and test execution. It may still need more features like uploading testing results which I plan to do as follow ups. Eventually this job will be called post bundle build job.
Issues Resolved
resolves #1322
Test
A successful run http://jenki-jenki-fpgmrv2ryxko-1366042710.us-east-1.elb.amazonaws.com/job/test-osd-tianleh/11/
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.