Closed smlambert closed 3 years ago
I like the explicit nature of the 2 separate params, but definitely think the Grinder job config would be nicer to use by collapsing the params. Let's use this issue to discuss pros/cons.
I really like the idea. This will make Grinder so much easy to use. No more typing! I can see this been used for most of our repo and branch parameters, but I am not sure about ADOPTOPENJDK_REPO
and ADOPTOPENJDK_BRANCH
.
Currently, we use them in job configure, so the job can check out specific ADOPTOPENJDK_REPO
and ADOPTOPENJDK_BRANCH
.
If we change ADOPTOPENJDK_REPO
and ADOPTOPENJDK_BRANCH
into one parameter, I am not sure how to use it in the job configure.
Ah good call, so maybe ADOPTOPENJDK_REPO and ADOPTOPENJDK_BRANCH keep their current status of unique individual parameters, since they represent the seed/base/starter repo, and other tangential repos shift to the collapsed single parameter, not quite as clean, but it still reduction.
If ADOPTOPENJDK_REPO_BRANCH = "AdoptOpenJDK:master" Doubt its possible to change the Repository URL and Branch specifier to contain groovy code or if they only allow for variables but if it were possible, perhaps could parse and fill with some string methods... where ADOPTOPENJDK_BRANCH is substring(${ADOPTOPENJDK_REPO_BRANCH}.indexOf(‘:’))
Thanks Shelley. I will give it a try.
PR #1940 and PR #1941 combined repo/branch names for TKG, stf, openjdk-systemtest and openj9-systemtest.
Remaining repos:
I think the remaining 3 repos are not easily collapsed into a single param (as there are variants and/or reasons that make it impossible to assume defaults), given this, we can likely mark this issue as closed. Do you agree @llxia ?
yes, close this issue.
For each of the REPO and BRANCH parameter pairs we have, we can reduce the 2 parameters to a single string, this would not only reduce the number of parameters, but also allow for cut'n'paste when launching Grinders during review.
(repo:branch is typically listed at the top right in Github PR, which could then be cut'n'pasted into the Grinder fields when running Grinders during review)
In Jenkinsfilebase (or TKG if we want to do this at the lower layer), logic to parse the single string into REPO and BRANCH. One caveat is if we proceed with https://github.com/AdoptOpenJDK/openjdk-tests/issues/1872 then parsing logic would also have to look at other information, example vendor info, to avoid making assumptions about repo location
Reduces 14 params down to 7 (if you count in JDK_REPO/BRANCH from proposal #1872):