Conversation
antonio-lunarg
left a comment
There was a problem hiding this comment.
Once addressing my comment, LGTM
267514b to
ed966ce
Compare
ed966ce to
0c237c1
Compare
mikes-lunarg
left a comment
There was a problem hiding this comment.
LGTM, just one question
| python3 VulkanTests/gfxrecontest.py --os AndroidTestOS --build-mode $BUILD_MODE $ANDROID_TEST_ARGS --suite "ci-gfxr-suites/$GFXRECON_TRACE_SUBDIR/$TEST_SUITE" --trace-dir "$GFXRECON_TRACE_DIR" --result-dir "$RESULTS_DIR" No newline at end of file | ||
|
|
||
| python3 -m venv $WORKSPACE/python-venv | ||
| $WORKSPACE/python-venv/bin/python3 -m pip install --no-cache-dir -r VulkanTests/requirements.txt > $WORKSPACE/python-venv.txt 2>&1 |
There was a problem hiding this comment.
I'm curious if there is a specific reason to use the full venv python executable path instead of using python-venv/bin/activate
There was a problem hiding this comment.
Here, to be as consistent as possible with other CI.
In "mainline" CI, the test script typically starts with the current directory in the repository code, but sometimes the current directory is in the workspace root.
Using the absolute path to $WORKSPACE works in all cases.
In a related issue... we could just create the venv wherever we are (whether it's the workspace root or the repository root) - but it turns out creating the venv in the VulkanTests or ci-servers repository root breaks their tests, because their tests search for all Python files within the repository root and runs pylint on them. Creating the venv inside the repository root taints the repository with hundreds of additional Python files that don't pass pylint and causes tests to fail.
So we always create the venv explicitly in the workspace root, and we always refer to it directly in the workspace root for consistency both with its creation and with its use across all Jenkins jobs.
0c237c1 to
c7f69cf
Compare
|
Squashing and rebasing to bring branch up-to-date |
As per:
Use venv and do install for all jobs that use VulkanTests
LunarG/Projects#1018
this updates the Jenkins integration for GFXReconstruct pipelines to use the
common boilerplate now used for all Jenkins multi-configuration jobs, including the
creation and use of a Python virtual environment, as per:
https://github.com/LunarG/VulkanTests/blob/master/doc/administrator/jenkins-jobs.md
Other than the Python virtual environment, the pattern for checking out repositories
into a subdirectory has been modified as per current best practices, to use the
git "-C <subdirectory>" switch to manipulate the repository in the subdirectory instead
of explict "cd" commands; and artifact archival has been expanded to include the
"python-venv.txt" file created during Python virtual environment initialization, so
it can be examined in case of unexpected failure.
ci/runJob.bat:
- Windows implementation
ci/runJob.sh:
- Mac and Linux implementation
ci/runJobAndroid.sh:
- Android on Linux host implementation
ci/runJob.groovy:
- update all artifact archival to include python-venv.txt
c7f69cf to
f34f1af
Compare
The first attempt here:
jenkins: use Python venv
LunarG#2722
was completely wrong; it modified files "runJob.bat", "runJob.sh", and "runJobAndroid.sh"
that aren't actually used in CI.
This effort modifies the "runTest.bat", "runTest.sh", and "runTestAndroid.sh" files
instead, which seems to be the correct way to affect CI behavior.
This PR temporarily includes a change to "test.ref" so that its testing will also evoke
the latest VulkanTests changes (which require a new Python module, and will clearly fail
if run without a Python virtual environment). The test.ref changes will be kept only
for testing, and will be removed before being merged.
As per:
Use venv and do install for all jobs that use VulkanTests
https://github.com/LunarG/Projects/issues/1018
this updates the Jenkins integration for GFXReconstruct pipelines to use the
common boilerplate now used for all Jenkins multi-configuration jobs, including the
creation and use of a Python virtual environment, as per:
https://github.com/LunarG/VulkanTests/blob/master/doc/administrator/jenkins-jobs.md
Other than the Python virtual environment, the pattern for checking out repositories
into a subdirectory has been modified as per current best practices, to use the
git "-C <subdirectory>" switch to manipulate the repository in the subdirectory instead
of explict "cd" commands; and artifact archival has been expanded to include the
"python-venv.txt" file created during Python virtual environment initialization, so
it can be examined in case of unexpected failure.
ci/runJob.bat:
- Windows implementation
ci/runJob.sh:
- Mac and Linux implementation
ci/runJobAndroid.sh:
- Android on Linux host implementation
ci/runJob.groovy:
- update all artifact archival to include python-venv.txt
The first attempt here:
jenkins: use Python venv
LunarG#2722
was completely wrong; it modified files "runJob.bat", "runJob.sh", and "runJobAndroid.sh"
that aren't actually used in CI.
This effort modifies the "runTest.bat", "runTest.sh", and "runTestAndroid.sh" files
instead, which seems to be the correct way to affect CI behavior.
This PR temporarily includes a change to "test.ref" so that its testing will also evoke
the latest VulkanTests changes (which require a new Python module, and will clearly fail
if run without a Python virtual environment). The test.ref changes will be kept only
for testing, and will be removed before being merged.
During testing I noticed an unexpected Windows warning:
C:\j\workspace\gfxr-pipelines_gfxr_PR-2753\gfxreconstruct\ci-gfxr-suites>ls .
'ls' is not recognized as an internal or external command,
operable program or batch file.
So I also fixed "cloneSuites.bat", which had a Linux "ls .", to use a Windows "dir" instead.
The first attempt here:
jenkins: use Python venv
#2722
was completely wrong; it modified files "runJob.bat", "runJob.sh", and "runJobAndroid.sh"
that aren't actually used in CI.
This effort modifies the "runTest.bat", "runTest.sh", and "runTestAndroid.sh" files
instead, which seems to be the correct way to affect CI behavior.
This PR temporarily includes a change to "test.ref" so that its testing will also evoke
the latest VulkanTests changes (which require a new Python module, and will clearly fail
if run without a Python virtual environment). The test.ref changes will be kept only
for testing, and will be removed before being merged.
During testing I noticed an unexpected Windows warning:
C:\j\workspace\gfxr-pipelines_gfxr_PR-2753\gfxreconstruct\ci-gfxr-suites>ls .
'ls' is not recognized as an internal or external command,
operable program or batch file.
So I also fixed "cloneSuites.bat", which had a Linux "ls .", to use a Windows "dir" instead.
As per:
this updates the Jenkins integration for GFXReconstruct pipelines to use the common boilerplate now used for all Jenkins multi-configuration jobs, including the creation and use of a Python virtual environment, as per:
Other than the Python virtual environment, the pattern for checking out repositories into a subdirectory has been modified as per current best practices, to use the git "-C " switch to manipulate the repository in the subdirectory instead of explict "cd" commands; and artifact archival has been expanded to include the "python-venv.txt" file created during Python virtual environment initialization, so it can be examined in case of unexpected failure.
ci/runJob.bat:
ci/runJob.sh:
ci/runJobAndroid.sh:
ci/runJob.groovy: