Jenkins build.xml files size #729
Labels
Comments
|
Is this issue resolve? I am facing the same issue. @joaocgreis |
You'd need to raise that with the Jenkins Git Plugin, in https://github.com/jenkinsci/git-plugin/. |
|
@jeevandongre Not on our end, and not upstream as far as I know. If you experiment with it, it would be great if you could share what works and what doesn't, might help us move it forward here. Thanks! |
|
ping -- is this still warning happening? |
|
Yes. For reference, the |
|
Changed the Looking quite good for now!For reference, the main things to look at when changing from plugin to script are the refspec and the branch to checkout. If we use this for jobs that don't fetch from the temporary repo, we'll have to look at keys as well. Windows batch scriptTASKKILL /T /F /FI "IMAGENAME eq node.exe"
TASKKILL /T /F /FI "IMAGENAME eq cctest.exe"
TASKKILL /T /F /FI "IMAGENAME eq run-tests.exe"
TASKKILL /T /F /FI "IMAGENAME eq msbuild.exe"
TASKKILL /T /F /FI "IMAGENAME eq mspdbsrv.exe"
TASKKILL /T /F /FI "IMAGENAME eq yes.exe"
IF EXIST .git/index.lock rm -rf .git
SET "ORIGIN_REFS=+refs/heads/master:refs/remotes/origin/master"
SET "ORIGIN_REFS=%ORIGIN_REFS% +refs/heads/v6.x-staging:refs/remotes/origin/v6.x-staging"
SET "ORIGIN_REFS=%ORIGIN_REFS% +refs/heads/v8.x-staging:refs/remotes/origin/v8.x-staging"
SET "ORIGIN_REFS=%ORIGIN_REFS% +refs/heads/v10.x-staging:refs/remotes/origin/v10.x-staging"
SET "ORIGIN_REFS=%ORIGIN_REFS% +refs/heads/v11.x-staging:refs/remotes/origin/v11.x-staging"
@REM Manual git
git --version
git init
git clean -fdx
git fetch --no-tags https://github.com/nodejs/node.git %ORIGIN_REFS%
if %errorlevel% neq 0 echo Problem fetching the main repo.
grep -q ^%TEMP_REPO_SERVER% %USERPROFILE%\.ssh\known_hosts || (ssh-keyscan -t rsa %TEMP_REPO_SERVER% >> %USERPROFILE%\.ssh\known_hosts)
echo off
FOR /F "delims=" %%F IN ('cygpath -u %JENKINS_TMP_KEY%') DO SET "GIT_SSH_COMMAND=ssh -i %%F"
echo on
git fetch --no-tags %TEMP_REPO% +refs/heads/%TEMP_BRANCH%*:refs/remotes/jenkins_tmp/%TEMP_BRANCH%*
if %errorlevel% neq 0 exit /b %errorlevel%
set "GIT_SSH_COMMAND="
git checkout -f jenkins_tmp/%TEMP_BRANCH%
if %errorlevel% neq 0 exit /b %errorlevel%
git reset --hard
if %errorlevel% neq 0 exit /b %errorlevel%
git clean -fdx
if %errorlevel% neq 0 exit /b %errorlevel%Shell script (not tested)#!bash -ex
(if [ -e .git/index.lock ]; then rm -rf .git; fi) || true
(if [ $(du -s .git | cut -f1) -gt 5000000 ]; then rm -rf .git; fi) || true
ORIGIN_REFS="+refs/heads/master:refs/remotes/origin/master"
ORIGIN_REFS="$ORIGIN_REFS +refs/heads/v6.x-staging:refs/remotes/origin/v6.x-staging"
ORIGIN_REFS="$ORIGIN_REFS +refs/heads/v8.x-staging:refs/remotes/origin/v8.x-staging"
ORIGIN_REFS="$ORIGIN_REFS +refs/heads/v10.x-staging:refs/remotes/origin/v10.x-staging"
ORIGIN_REFS="$ORIGIN_REFS +refs/heads/v11.x-staging:refs/remotes/origin/v11.x-staging"
# Manual git
git --version
git init
time git clean -fdx || true
time git fetch --no-tags https://github.com/nodejs/node.git $ORIGIN_REFS || echo "Problem fetching the main repo."
grep -q ^$TEMP_REPO_SERVER ~/.ssh/known_hosts || (mkdir -p ~/.ssh && ssh-keyscan -t rsa $TEMP_REPO_SERVER >> ~/.ssh/known_hosts)
time ssh-agent sh -c "ssh-add $JENKINS_TMP_KEY && git fetch --no-tags $TEMP_REPO +refs/heads/${TEMP_BRANCH}*:refs/remotes/jenkins_tmp/${TEMP_BRANCH}*"
rm -f $JENKINS_TMP_KEY
time git checkout -f refs/remotes/jenkins_tmp/$TEMP_BRANCH
time git reset --hard
time git clean -fdx |
|
The solution above fixed the issue for us. Essentially, stop using the Git plugin in the affected jobs. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
According to https://issues.jenkins-ci.org/browse/JENKINS-19022 , the Jenkins Git plugin stores information on
build.xmlthat seems pointless in our use case. A warning is print in every run, pointing to a page with a workaround:There was at least one PR to address this that did not land (jenkinsci/git-plugin#163) and another one that was reverted (jenkinsci/git-plugin#312).
Implementing the workaround is not trivial in our case because of security issues and we would risk breaking the current instance. At least, we should keep track of the situation upstream.
The text was updated successfully, but these errors were encountered: