You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For context, see nodejs/reliability#12 and the minutes of the last build meeting #1448 It was agreed to fix those workers by configuring git to not fix the line breaks.
autocrlf should not be changed in the Windows machines, we want to ensure new contributors can compile with a default installation of Git (we already ask for the Unix tools, but the less of those little details the better and some people might not want to change it). I understand this does not include Windows hosts for now, but there is support to run the V8 tests on Windows and the ChakraCore nightlies seem to be failing because of this.
@joaocgreis The failures in CI are caused by incorrect checkouts (not a fresh clone of nodejs/node), I don't see changing settings on our CI makes a difference since that's not how new contributors set up their environment anyway? For instance, developers don't see the modified: deps/v8/third_party/jinja2/LICENSE error, but we do.
I don't see changing settings on our CI makes a difference since that's not how new contributors set up their environment anyway?
It should be, Windows CI machines are set up in the same way that we recommend contributors to set their own (with a few additions for Jenkins). Using a different autocrlf setting in CI can cause tests to fail because of different line endings.
Please let me take a better look at this, I'd much rather find a solution that doesn't involve changing machine configuration.
I confirmed this is only a problem depending on the Git version. Happens with older versions (tested 1.9.1) but not with newer (2.18.0). nodejs/node#22340 (thanks for opening @joyeecheung!) should fix the problem, but in any case I'd be ok with changing the crlf settings only in machines where Git can't be updated.
we want to ensure new contributors can compile with a default installation of Git
That was my motivation as well. Setting git to not touch the files in any way would break Windows build in case file are improperly checked in (e.g. .bat file with just LF). So we will be actually testing if the code can compile even from tarball.
So we will be actually testing if the code can compile even from tarball.
Given that we have actually broken this in the past this would be better off as a separate job (that actually unpacks the tarball and attempts to compile/test it).
[iojs@test-linuxonecc-rhel72-s390x-3 rhel72-s390x]$ git status
# HEAD detached at 4b7cd4b
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: deps/v8/third_party/jinja2/LICENSE
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# build/
no changes added to commit (use "git add" and/or "git commit -a")
[iojs@test-linuxonecc-rhel72-s390x-3 rhel72-s390x]$ git checkout deps/v8/third_party/jinja2/LICENSE
[iojs@test-linuxonecc-rhel72-s390x-3 rhel72-s390x]$ git status
# HEAD detached at 4b7cd4b
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: deps/v8/third_party/jinja2/LICENSE
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# build/
no changes added to commit (use "git add" and/or "git commit -a")
[iojs@test-linuxonecc-rhel72-s390x-3 rhel72-s390x]$ git --version
git version 1.8.3.1
[iojs@test-linuxonecc-rhel72-s390x-3 rhel72-s390x]$ git config --global -l
core.autocrlf=false
core.safecrlf=false
core.eol=lf
[iojs@test-linuxonecc-rhel72-s390x-3 rhel72-s390x]$
I thought the errors would not appear if you are checking out from a commit without the CRLF file and not rebasing from somewhere that contains it? (but yeah, it'll appear the next time we have a file like that in deps/v8)
I thought the errors would not appear if you are checking out from a commit without the CRLF file and not rebasing from somewhere that contains it? (but yeah, it'll appear the next time we have a file like that in deps/v8)
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
Activity
joyeecheung commentedon Aug 15, 2018
Maybe we should just put the configuration in https://github.com/nodejs/build/blob/master/jenkins/scripts/node-test-commit-pre.sh instead?
richardlau commentedon Aug 15, 2018
+1 for configuration changes in scripts rather than manually done.
joyeecheung commentedon Aug 15, 2018
Also, as far as I can tell the containers have their configs set in the Jenkins instead of using the script
joaocgreis commentedon Aug 15, 2018
autocrlfshould not be changed in the Windows machines, we want to ensure new contributors can compile with a default installation of Git (we already ask for the Unix tools, but the less of those little details the better and some people might not want to change it). I understand this does not include Windows hosts for now, but there is support to run the V8 tests on Windows and the ChakraCore nightlies seem to be failing because of this.@joyeecheung can we instead use https://github.com/nodejs/node/blob/master/.gitattributes to specify that that file is always CRLF? This is already done for
vcbuild.bat.joyeecheung commentedon Aug 15, 2018
@joaocgreis The failures in CI are caused by incorrect checkouts (not a fresh clone of nodejs/node), I don't see changing settings on our CI makes a difference since that's not how new contributors set up their environment anyway? For instance, developers don't see the
modified: deps/v8/third_party/jinja2/LICENSEerror, but we do.joyeecheung commentedon Aug 15, 2018
Does that work with https://github.com/nodejs/node/blob/8a41470c85536119a6dbeaf4b40dc9ebc4c453c4/deps/v8/.gitattributes#L1-L2 ? It's a file in
deps/v8but not actually in V8's upstream source, and V8 actually uses LF for all its own text files in its own.gitattributesjoaocgreis commentedon Aug 15, 2018
It should be, Windows CI machines are set up in the same way that we recommend contributors to set their own (with a few additions for Jenkins). Using a different
autocrlfsetting in CI can cause tests to fail because of different line endings.Please let me take a better look at this, I'd much rather find a solution that doesn't involve changing machine configuration.
joyeecheung commentedon Aug 15, 2018
As it's a file maintained by us and not in V8's source, maybe we can just patch it to use LF? That way it won't conflict with
deps/v8/.gitattributesjoaocgreis commentedon Aug 15, 2018
That sounds good to me, if @targos is ok with it.
joaocgreis commentedon Aug 15, 2018
I confirmed this is only a problem depending on the Git version. Happens with older versions (tested 1.9.1) but not with newer (2.18.0). nodejs/node#22340 (thanks for opening @joyeecheung!) should fix the problem, but in any case I'd be ok with changing the
crlfsettings only in machines where Git can't be updated.refack commentedon Aug 15, 2018
That was my motivation as well. Setting git to not touch the files in any way would break Windows build in case file are improperly checked in (e.g.
.batfile with justLF). So we will be actually testing if the code can compile even from tarball.richardlau commentedon Aug 15, 2018
Given that we have actually broken this in the past this would be better off as a separate job (that actually unpacks the tarball and attempts to compile/test it).
2 remaining items
deps: fix CRLF in text file not present in upstream
refack commentedon Aug 18, 2018
I run this groovy script:
to get:
refack commentedon Aug 18, 2018
Also for good measure run with
agent.name ==~ /(?i).*linuxone.*/:deps: fix CRLF in text file not present in upstream
refack commentedon Aug 20, 2018
Help, this can't be killed:
refack commentedon Aug 20, 2018
So apparently with git 1.8 we need to delete the workspace for the settings to work.
joyeecheung commentedon Aug 20, 2018
I thought the errors would not appear if you are checking out from a commit without the CRLF file and not rebasing from somewhere that contains it? (but yeah, it'll appear the next time we have a file like that in deps/v8)
refack commentedon Aug 20, 2018
I was testing explicitly with "bad" commits:
https://ci.nodejs.org/job/node-test-commit-linuxone/4190/
When everything is setup right, it passes.
deps: fix CRLF in text file not present in upstream
github-actions commentedon Mar 8, 2020
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.