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

Automate integration tests jenkins job #1429

Merged
merged 21 commits into from
Jan 18, 2022

Conversation

ohltyler
Copy link
Member

@ohltyler ohltyler commented Jan 5, 2022

Description

This PR updates the existing integ test jenkins workflow, which currently doesn't work and is using outdated parameters.

More specifically:

  • moves and updates existing test workflow (jenkins/test/testsuite/Jenkinsfile) to jenkins/opensearch/integ-test.jenkinsfile. Params were modified to try to prevent link-building logic which has caused broken builds in the past.
  • adds runIntegTestScript groovy script to execute the actual test shell script
  • adds getBuildManifestInfo groovy script to use the passed-in build manifest URL to pull out build-related information

There will be follow up PRs to finish automating integration tests:

  1. Update distribution-build workflow to trigger the integ tests after building x64 and arm64 artifacts
  2. Remove legacy jenkins test code (in jenkins/test) and associated READMEs

NOTE: this PR is a WIP for now. Things to wrap up before it is ready:

  • investigate passing full manifest file to test.sh instead of root URL
  • adding publishNotifications() back

Screenshot - working integ test job
Screen Shot 2022-01-13 at 9 17 44 AM

Issues Resolved

Closes #1114

Check List

  • Commits are signed per the DCO using --signoff

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.

@ohltyler ohltyler requested a review from a team as a code owner January 5, 2022 23:23
@ohltyler ohltyler marked this pull request as draft January 5, 2022 23:24
@codecov-commenter
Copy link

codecov-commenter commented Jan 5, 2022

Codecov Report

Merging #1429 (e292c13) into main (eb7c932) will decrease coverage by 0.05%.
The diff coverage is 33.33%.

Impacted file tree graph

@@             Coverage Diff              @@
##               main    #1429      +/-   ##
============================================
- Coverage     94.45%   94.40%   -0.06%     
  Complexity       12       12              
============================================
  Files           141      144       +3     
  Lines          3084     3090       +6     
  Branches          8        8              
============================================
+ Hits           2913     2917       +4     
- Misses          164      166       +2     
  Partials          7        7              
Impacted Files Coverage Δ
src/jenkins/BuildManifest.groovy 92.00% <33.33%> (-8.00%) ⬇️
tests/jenkins/jobs/uploadSnapshotsToS3_Jenkinsfile 100.00% <0.00%> (ø)
...PromoteArtifacts_OpenSearch_Dashboards_Jenkinsfile 100.00% <0.00%> (ø)
...rtifacts_actions_OpenSearch_Dashboards_Jenkinsfile 100.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eb7c932...e292c13. Read the comment docs.

@ohltyler ohltyler force-pushed the automate-integ-test branch 2 times, most recently from 21e64ac to 996452d Compare January 5, 2022 23:41
// script {
// def stashed = lib.jenkins.Messages.new(this).get(['build-x64', 'build-arm64'])

// publishNotification(
Copy link
Member

Choose a reason for hiding this comment

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

You can comment out the body of publishNotification which may be easier than commenting out the steps everywhere ;)

jenkins/opensearch/integ-test.jenkinsfile Show resolved Hide resolved
@ohltyler ohltyler force-pushed the automate-integ-test branch from d5bf1c7 to 4337856 Compare January 7, 2022 00:10
jenkins/opensearch/integ-test.jenkinsfile Outdated Show resolved Hide resolved
vars/runIntegTests.groovy Outdated Show resolved Hide resolved
vars/runIntegTests.groovy Outdated Show resolved Hide resolved
vars/runIntegTests.groovy Outdated Show resolved Hide resolved
vars/runIntegTests.groovy Outdated Show resolved Hide resolved
@tianleh
Copy link
Member

tianleh commented Jan 10, 2022

FYI. I have a task to trigger OpenSearch Dashboards integ test post bundle build #1372 We can sync up to see if we can leverage each other's work.

Copy link
Contributor

@abhinavGupta16 abhinavGupta16 left a comment

Choose a reason for hiding this comment

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

Let's have test cases for all the jenkinsfile that are added.

  • distribution-build.jenkinsfile
  • integ-test.jenkinsfile

@ohltyler
Copy link
Member Author

Let's have test cases for all the jenkinsfile that are added.

  • distribution-build.jenkinsfile
  • integ-test.jenkinsfile

Tests have been added for integ-test.jenkinsfile via runIntegTests.groovy, and is tested via TestRunIntegTests.groovy.
distribution-build.jenkinsfile already exists, and is essentially a compilation of a bunch of these groovy scripts that already have associated tests. Since there is no related groovy script for this one, I don't know how else to test.

I'm not aware of any other ways to test these in an automated way, do you have any suggestion?

@ohltyler ohltyler force-pushed the automate-integ-test branch from 041e4d4 to dcdaa2f Compare January 10, 2022 21:50
@ohltyler ohltyler marked this pull request as ready for review January 10, 2022 21:57
@abhinavGupta16
Copy link
Contributor

abhinavGupta16 commented Jan 10, 2022

Let's have test cases for all the jenkinsfile that are added.

  • distribution-build.jenkinsfile
  • integ-test.jenkinsfile

Tests have been added for integ-test.jenkinsfile via runIntegTests.groovy, and is tested via TestRunIntegTests.groovy. distribution-build.jenkinsfile already exists, and is essentially a compilation of a bunch of these groovy scripts that already have associated tests. Since there is no related groovy script for this one, I don't know how else to test.

I'm not aware of any other ways to test these in an automated way, do you have any suggestion?

TestRunIntegTests.groovy should only test runIntegTests.groovy like a unit test. integ-test.jenkinsfile is a jenkins job that may or may not use more functionalities and libraries in the future apart from runIntegTests.groovy and therefore should be tested separately.

We can add tests for the intire job ina very similar way to what we do for our libraries. You can refer to this as reference. I hope this helps

@ohltyler
Copy link
Member Author

Let's have test cases for all the jenkinsfile that are added.

  • distribution-build.jenkinsfile
  • integ-test.jenkinsfile

Tests have been added for integ-test.jenkinsfile via runIntegTests.groovy, and is tested via TestRunIntegTests.groovy. distribution-build.jenkinsfile already exists, and is essentially a compilation of a bunch of these groovy scripts that already have associated tests. Since there is no related groovy script for this one, I don't know how else to test.
I'm not aware of any other ways to test these in an automated way, do you have any suggestion?

TestRunIntegTests.groovy should only test runIntegTests.groovy like a unit test. integ-test.jenkinsfile is a jenkins job that may or may not use more functionalities and libraries in the future apart from runIntegTests.groovy and therefore should be tested separately.

We can add tests for the intire job ina very similar way to what we do for our libraries. You can refer to this as reference. I hope this helps

Link seems to be broken. I'm still unsure what you mean

Copy link
Member

@peternied peternied left a comment

Choose a reason for hiding this comment

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

Looking really close, could you remove all the commented out code at this point?

@abhinavGupta16
Copy link
Contributor

abhinavGupta16 commented Jan 10, 2022

Let's have test cases for all the jenkinsfile that are added.

  • distribution-build.jenkinsfile
  • integ-test.jenkinsfile

Tests have been added for integ-test.jenkinsfile via runIntegTests.groovy, and is tested via TestRunIntegTests.groovy. distribution-build.jenkinsfile already exists, and is essentially a compilation of a bunch of these groovy scripts that already have associated tests. Since there is no related groovy script for this one, I don't know how else to test.
I'm not aware of any other ways to test these in an automated way, do you have any suggestion?

TestRunIntegTests.groovy should only test runIntegTests.groovy like a unit test. integ-test.jenkinsfile is a jenkins job that may or may not use more functionalities and libraries in the future apart from runIntegTests.groovy and therefore should be tested separately.
We can add tests for the intire job ina very similar way to what we do for our libraries. You can refer to this as reference. I hope this helps

Link seems to be broken. I'm still unsure what you mean

This file tests the signArtifacts.groovy as a function only by creating a dummy pipline in tests/jenkins/job and there is also a test to test the entire sign-standalone-artifacts.jenkinsfile

binding.setVariable('URLs', 'https://www.dummy.com/dummy_1_artifact.tar.gz,' +
' https://www.dummy.com/dummy_2_artifact.tar.gz')
binding.setVariable('S3_FILE_UPLOAD_PATH', '/dummy/upload/path/')
binding.setVariable('JOB_NAME', 'sign_artifacts_job')
binding.setVariable('BUILD_NUMBER', '20')
binding.setVariable('ARTIFACT_DOWNLOAD_ROLE_NAME', 'Dummy_Download_Role')
binding.setVariable('ARTIFACT_UPLOAD_ROLE_NAME', 'Dummy_Upload_Role')
binding.setVariable('AWS_ACCOUNT_PUBLIC', 'dummy_account')
binding.setVariable('ARTIFACT_BUCKET_NAME', 'dummy_bucket_name')
helper.registerAllowedMethod("cleanWs", [Map])
helper.registerAllowedMethod("s3Upload", [Map])
helper.registerAllowedMethod("withAWS", [Map, Closure], { args, closure ->
closure.delegate = delegate
return helper.callClosure(closure)
})
super.testPipeline("jenkins/sign-artifacts/sign-standalone-artifacts.jenkinsfile", "tests/jenkins/jenkinsjob-regression-files/sign-standalone-artifacts.jenkinsfile")

Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

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

Are we using/will we ever use jenkins/test/orchestrator/Jenkinsfile?

I'm good with this putting back notifications and removing any Tyler-references ;)

jenkins/opensearch/integ-test.jenkinsfile Outdated Show resolved Hide resolved
vars/runIntegTests.groovy Outdated Show resolved Hide resolved
@ohltyler
Copy link
Member Author

ohltyler commented Jan 11, 2022

Are we using/will we ever use jenkins/test/orchestrator/Jenkinsfile?

I'm good with this putting back notifications and removing any Tyler-references ;)

I think the framework is worth leaving for now, to help with future work at getting the entire test orchestrator running. I imagine we will want the distribution build and/or other test pipelines to be able to kick off all integ/perf/bwc tests

cc @peternied

@dblock
Copy link
Member

dblock commented Jan 11, 2022

Are we using/will we ever use jenkins/test/orchestrator/Jenkinsfile?
I'm good with this putting back notifications and removing any Tyler-references ;)

I think the framework is worth leaving for now, to help with future work at getting the entire test orchestrator running. I imagine we will want the distribution build and/or other test pipelines to be able to kick off all integ/perf/bwc tests

cc @peternied

my vote is to nuke anything unused (and doesn't work), and move it to a link to a specific commit for anyone who wants to resurrect it when it's ready to be used

@ohltyler
Copy link
Member Author

ohltyler commented Jan 11, 2022

Are we using/will we ever use jenkins/test/orchestrator/Jenkinsfile?
I'm good with this putting back notifications and removing any Tyler-references ;)

I think the framework is worth leaving for now, to help with future work at getting the entire test orchestrator running. I imagine we will want the distribution build and/or other test pipelines to be able to kick off all integ/perf/bwc tests
cc @peternied

my vote is to nuke anything unused (and doesn't work), and move it to a link to a specific commit for anyone who wants to resurrect it when it's ready to be used

From my understanding this project was close to complete and was somewhat working at one time, but has fallen behind regarding parameters being passed, etc. There's mentions in the READMEs (e.g. here) about this orchestrator project and tracking github issues for them. Do you think it's worth removing all of this, or leaving as-is and just making sure the tracking issues in the READMEs are up-to-date?

@peternied
Copy link
Member

my vote is to nuke anything unused (and doesn't work)

+1; however, I am comfortable with making this a new PR focused on removing these components and fixing the documentation

Copy link
Member

@peternied peternied left a comment

Choose a reason for hiding this comment

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

We did a deep dive today, and that resulted in some things coming out. I'd recommend doing some smaller PRs that would make this more manageable.

jenkins/opensearch/distribution-build.jenkinsfile Outdated Show resolved Hide resolved
jenkins/opensearch/integ-test.jenkinsfile Outdated Show resolved Hide resolved
jenkins/opensearch/integ-test.jenkinsfile Outdated Show resolved Hide resolved
jenkins/opensearch/integ-test.jenkinsfile Show resolved Hide resolved
jenkins/test/orchestrator/Jenkinsfile Outdated Show resolved Hide resolved
@@ -49,6 +51,23 @@ class BuildManifest implements Serializable {
this.getArtifactRoot(jobName, buildNumber)
].join('/')
}

public String getDistUrl(String publicArtifactUrl = 'https://ci.opensearch.org/ci/dbc', String jobName, String buildNumber) {
Copy link
Member

Choose a reason for hiding this comment

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

This function is used to reverse engineer the url so we can pass in the root path to the test system. Instead could we update the python code to accept the full path to the build manifest? It reduces the number of parameters we pass around greatly

Copy link
Member Author

Choose a reason for hiding this comment

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

After looking further, it looks like the root path is used, because both the build manifest (ending in /builds/opensearch/manifest.yml) and the bundle manifest (ending in /dist/opensearch/manifest.yml) are both used for a few things in the dependency installer - the build manifest is used for downloading maven dependencies, and the bundle manifest is used for downloading the distribution (via location param stored in the bundle manifest).

I prefer to keep the root url rather than add parameters here to keep the interface simpler. It's already a bit complex when running Dashboards tests since multiple root urls are needed already. Lmk what you think.

Copy link
Member Author

@ohltyler ohltyler Jan 12, 2022

Choose a reason for hiding this comment

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

Also note that getDistUrl() in particular is only used in the distribution-build workflow to generate the build manifest url to pass to the integ-test workflow. The existing getArtifactRootUrl() is the one used for reverse engineering currently, and is called in runIntegTestScript.groovy.

Copy link
Member

Choose a reason for hiding this comment

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

We should consider taking build output such as maven and promoting it to the distribution manifest so we can use a single manifest as input.

Copy link
Member Author

Choose a reason for hiding this comment

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

Wouldn't this be blending the purposes of these manifests too much? From my understanding, the build manifest is for listing out the artifacts and related dependencies per component that are included in the build. The bundle/distribution manifest is a simplified list of built components, with references to their build locations.

Agreed there is quite a bit of overlap between the two though, where maybe it's worth considering merging these into a single manifest? I may not have the most context for why it was designed this way to begin with, but I feel that only one may be needed.

Copy link
Member

Choose a reason for hiding this comment

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

Agreed. It's beyond the scope of this issue, but the idea was that the same build is being used to assemble a different distribution, e.g. cross-platform.

vars/getBuildManifestInfo.groovy Outdated Show resolved Hide resolved
vars/runIntegTestScript.groovy Show resolved Hide resolved
vars/runIntegTestScript.groovy Outdated Show resolved Hide resolved
parameters: [
string(name: 'TEST_MANIFEST', value: "${testManifest}"),
string(name: 'BUILD_MANIFEST_URL', value: "${buildManifest}"),
]
Copy link
Member

Choose a reason for hiding this comment

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

We should add the parameter wait: false so that the build workflow isn't blocked
We should also add the parameter propagate: false so if the tests pass/fail it doesn't impact the distribution-build job.

Copy link
Member Author

@ohltyler ohltyler Jan 12, 2022

Choose a reason for hiding this comment

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

Similar to my question here, how do we want to go about test failures/successes impacting the jenkins jobs?

I see 2 main paths forward:

  1. Fail the step if the tests failed, which would cause the entire job to fail
  2. distribution-build Jenkins job should always succeed (assuming no syntax / other workflow-related bugs), and test success/failure is handled via notifications and/or other jenkins jobs that will fail if the tests fail (maybe integ-test itself?)

Copy link
Member

Choose a reason for hiding this comment

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

  1. I put a more detail reply on that first question, for now only job failure == workflow failure is more useful because we are using as we are building so we are still focused on stability of the workflow

  2. As you've written it I think so. Note; I think we can revisit this when we have an automated action like 'deploy to production' that has the required pre-reqs run. I think we would want to make sure things like 8+ hour long build jobs are still correcting rolling up state across different workflows.

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, I think that makes a lot of sense. We can follow this fail-fast strategy for now.

@ohltyler
Copy link
Member Author

my vote is to nuke anything unused (and doesn't work)

+1; however, I am comfortable with making this a new PR focused on removing these components and fixing the documentation

Got it, makes sense. I'll update #1447 with some details and resolve in a separate PR

@ohltyler
Copy link
Member Author

We did a deep dive today, and that resulted in some things coming out. I'd recommend doing some smaller PRs that would make this more manageable.

To break this up easier, I'm thinking of splitting this up into 3 parts / PRs:

  1. Revive old integ test workflow and get a working version via jenkins/opensearch/integ-test.jenkinsfile (this PR)
  2. Hook new integ test workflow into distribution build workflow (jenkins/opensearch/distribution-build.jenkinsfile) (future PR)
  3. Remove legacy integ-test jenkins code in jenkins/test/ and update related READMEs (future PR)

@ohltyler ohltyler marked this pull request as draft January 11, 2022 23:18
@ohltyler ohltyler force-pushed the automate-integ-test branch 2 times, most recently from 2654e7d to fa6873f Compare January 12, 2022 01:12
@ohltyler ohltyler changed the title Automate integration tests after bundle build Automate integration tests jenkins job Jan 12, 2022
@ohltyler ohltyler force-pushed the automate-integ-test branch from 9a43de4 to 83580f3 Compare January 12, 2022 23:36
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
…tegTests()

Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
…rious cleanup

Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
…eters comments

Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
@ohltyler ohltyler force-pushed the automate-integ-test branch from 83580f3 to 386794e Compare January 12, 2022 23:42
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
…ad of bundle

Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
@ohltyler ohltyler marked this pull request as ready for review January 13, 2022 17:17
Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

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

This looks great. I have strong feelings about the utility library, WDYT?

String buildId = buildManifest.getArtifactBuildId()

return [buildManifestPath, buildId]
}
Copy link
Member

@dblock dblock Jan 13, 2022

Choose a reason for hiding this comment

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

Returning a tuple limits the utility of this shared function. As suggested bellow, maybe something like downloadBuildManifest that downloads the remote manifest and returns the buildManifest object, then all the future uses are available to the caller. I can see another workflow needing to download the manifest but use some other manifest property like platform.

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed this is a better approach, changed to downloadBuildManifest() in c60435a

steps {
script {
// Fetching the build-specific values and assigning to their env vars
(buildManifestPath, buildId) = getBuildManifestInfo()
Copy link
Member

@dblock dblock Jan 13, 2022

Choose a reason for hiding this comment

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

This API is strange, I'd prefer it'd download a manifest and return that.

def buildManifest = downloadBuildManifest(manifest: "${BUILD_MANIFEST_URL}")
...

Copy link
Member

Choose a reason for hiding this comment

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

I much prefer this approach. Functions with no side effects are my jam

Copy link
Member

@dblock dblock Jan 14, 2022

Choose a reason for hiding this comment

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

Do you mean you prefer the version as implemented now in the PR?

Note that shared functions are global. This one does not "get build manifest info", it "get some very specific build manifest info used in integ-test workflow", are we going to be adding another function like this when we need some other value from a remote manifest that will be an identical copy but return different fields?

Copy link
Member Author

Choose a reason for hiding this comment

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

I've updated this, see #1429 (comment)

vars/getBuildManifestInfo.groovy Outdated Show resolved Hide resolved
Copy link
Member

@peternied peternied left a comment

Choose a reason for hiding this comment

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

Great work!

jenkins/opensearch/integ-test.jenkinsfile Show resolved Hide resolved
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
@ohltyler ohltyler merged commit cbeffeb into opensearch-project:main Jan 18, 2022
peterzhuamazon pushed a commit to peterzhuamazon/opensearch-build that referenced this pull request Feb 16, 2022
Signed-off-by: Tyler Ohlsen <ohltyler@amazon.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Trigger integ-test workflow after build workflow finishes
6 participants