-
-
Notifications
You must be signed in to change notification settings - Fork 314
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
Generate property file with SHA info #2889
Comments
I will take this for now, I'll likely end up breaking it into smaller issues like recommended. |
Thanks @psaunderualberta . Please check meeting recording for details. For the first issue - generate the testenv.properties file and archive testenv.properties |
preliminary |
Related: adoptium/TKG#255 Related: adoptium#2889 Signed-off-by: lanxia lan_xia@ca.ibm.com
Currently, we take both OPENJ9_BRANCH and OPENJ9_SHA. However, in testenv.properties, we only output one value - OPENJ9_SHA (adoptium/TKG#255). We will not have branch information. The logic in `get.sh` was highly optimized to have minimal checkout for openj9 repo (i.e., we do not fetch other branches). This causes a problem as it is not able to git clone with sha only (if the sha is from other branch). This PR adds the support to git clone personal openj9 sha without branch info, so we can consume the OPENJ9_SHA without OPENJ9_BRNACH info. Related: adoptium/TKG#255 Related: adoptium#2889 Signed-off-by: lanxia lan_xia@ca.ibm.com
Currently, we take both OPENJ9_BRANCH and OPENJ9_SHA. However, in testenv.properties, we only output one value - OPENJ9_SHA (adoptium/TKG#255). We will not have branch information. The logic in `get.sh` was highly optimized to have minimal checkout for openj9 repo (i.e., we do not fetch other branches). This causes a problem as it is not able to git clone with sha only (if the sha is from other branch). This PR adds the support to git clone personal openj9 sha without branch info, so we can consume the OPENJ9_SHA without OPENJ9_BRNACH info. Related: adoptium/TKG#255 Related: adoptium#2889 Signed-off-by: lanxia lan_xia@ca.ibm.com
Currently, we take both OPENJ9_BRANCH and OPENJ9_SHA. However, in testenv.properties, we only output one value - OPENJ9_SHA (adoptium/TKG#255). We will not have branch information. The logic in `get.sh` was highly optimized to have minimal checkout for openj9 repo (i.e., we do not fetch other branches). This causes a problem as it is not able to git clone with sha only (if the sha is from other branch). This PR adds the support to git clone personal openj9 sha without branch info, so we can consume the OPENJ9_SHA without OPENJ9_BRNACH info. Related: adoptium/TKG#255 Related: #2889 Signed-off-by: lanxia lan_xia@ca.ibm.com
I believe this one is now addressed, closing as complete. |
Currently, we generate SHA.txt for capture test repo shas. This file is easy to read, but it can not be used directly to set env value.
Maybe it is easier to create a property file with key and value pairs. The key should match with get.sh parameters and values in ant build.xml. For example in
testenv.properties
file, we haveIn get.sh, we can simply add
source ./testenv.properties
to load the variables (i.e., TKG_REPO, TKG_BRANCH, etc).For ant (build.xml) to work, the variables need to be set as env variables (i.e., JDK_REPO, JDK_BRANCH, etc).
or
IMO, option2 seems better as it will cover the local run as well.
In Grinder, add a boolean flag
USE_TESTENV_PROPERTIES
. If it is set to true, ignore the params in Grinder, readtestenv.properties
and set values as env variable (override params if set) for ant scripts and run get.sh.And If the flag is set to true, we are expecting to find the file under root
testenv.properties
. Print error and exit the build if this file cannot be found. This logic should be in get.sh.If it is set to false, proceed as a regular run (that is take the parameters from Grinder).
Please test both the local and Grinder run.
Update: broken into several steps:
testenv.properties
file and archivetestenv.properties
USE_TESTENV_PROPERTIES
flag, consumetestenv.properties
in get.shtestenv.properties
in system teststestenv.properties
in openjdk testsThe text was updated successfully, but these errors were encountered: