pass test run id when running tests from Jenkins

[tianleh]

Signed-off-by: Tianle Huang tianleh@amazon.com

Description

Currently the test result can be accessed by a url with a random value https://ci.opensearch.org/ci/dbc/integ-test-opensearch-dashboards/1.3.0/1493/linux/arm64/test-results/e4fe62b882294caabd99701b6d0b612f/integ-test/functionalTestDashboards/without-security/test-results/stdout.txt

This will require us to check the S3 to get the full url which is very inconvenient. Thus set a value to the id so that we can use latest url to check the results.

Issues Resolved

[List any issues this PR will resolve]

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.

[codecov-commenter]

Codecov Report

Merging #2024 (8741b7c) into main (8ebd79d) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main    #2024   +/-   ##
=========================================
  Coverage     94.17%   94.17%           
  Complexity       25       25           
=========================================
  Files           195      195           
  Lines          3860     3860           
  Branches         29       29           
=========================================
  Hits           3635     3635           
  Misses          219      219           
  Partials          6        6           

---

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 8ebd79d...8741b7c. Read the comment docs.

[kavilla]

This is cool. I wonder if we should consider actually passing the number from Jenkins it won't always be 1 though but it will match the jenkins pipeline I do think people can end up running a build pipeline of their own but have it pointing to the integ test job for OpenSearch and potentially being some conflict here if the random value always equals 1.

Another followup, I think I added this re-using the same stuff that was setup for OpenSearch tests. But perhaps we should consider uploading the test results to the distribution-builds folder for that specific build as well?

[peterzhuamazon]

The folder on S3 already include the build number?

[kavilla]

The folder on S3 already include the build number?

Yeah I mean the build number from the integ test job. Right now it uses the build number from the distribution build job. For example, if I build OpenSearch Dashboards and the build number is 3014 for the build job, when the test job gets triggered, it will upload to osd-test-job/3014/../1/ even if I just re-run the test job, where as before I can trigger the test job and it would be like osd-test-job/3014/../randomhash/ so then there is no conflicts.

So if a non-prod build job points to the prod test job where the versions match and the build number (for example 3014) is the same it could potentially have a playground build test results replace tests results (or conflict)

[tianleh]

Yeah I mean the build number from the integ test job. Right now it uses the build number from the distribution build job. For example, if I build OpenSearch Dashboards and the build number is 3014 for the build job, when the test job gets triggered, it will upload to osd-test-job/3014/../1/ even if I just re-run the test job, where as before I can trigger the test job and it would be like osd-test-job/3014/../randomhash/ so then there is no conflicts.

So if a non-prod build job points to the prod test job where the versions match and the build number (for example 3014) is the same it could potentially have a playground build test results replace tests results (or conflict)

Current integ test job is using its own job name. One recent example of my playground integ test job
https://ci.opensearch.org/ci/dbc/Playground/tianleh-test/tianleh-osd-integ-test-4-21/2.0.0-rc1/3014/linux/arm64/tar/test-results/1/integ-test/functionalTestDashboards/with-security/test-results/stdout.txt

It is uploading to my playground S3 bucket instead of the prod integ test.

@kavilla @peterzhuamazon

[tianleh]

Yeah I mean the build number from the integ test job. Right now it uses the build number from the distribution build job. For example, if I build OpenSearch Dashboards and the build number is 3014 for the build job, when the test job gets triggered, it will upload to osd-test-job/3014/../1/ even if I just re-run the test job, where as before I can trigger the test job and it would be like osd-test-job/3014/../randomhash/ so then there is no conflicts.

So if a non-prod build job points to the prod test job where the versions match and the build number (for example 3014) is the same it could potentially have a playground build test results replace tests results (or conflict)

For the part about non-prod build job pointing to prod test job, the buildManifestUrl passed to the job will be different. I think the non-prod one will not build so often and thus the latest results should be fine.

To solve this, I think we can add the parent job name as part of the S3 folder. Or as @kavilla suggested, "Another followup, I think I added this re-using the same stuff that was setup for OpenSearch tests. But perhaps we should consider uploading the test results to the distribution-builds folder for that specific build as well?"