Re: [PATCH 2/2] travis-ci: check that all build artifacts are .gitignore-d

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 03 Jan 2018, at 00:12, SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
> 
> On Tue, Jan 2, 2018 at 8:40 PM, Lars Schneider <larsxschneider@xxxxxxxxx> wrote:
>> 
>>> On 31 Dec 2017, at 17:02, SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote:
>>> 
>>> Every once in a while our explicit .gitignore files get out of sync
>>> when our build process learns to create new artifacts, like test
>>> helper executables, but the .gitignore files are not updated
>>> accordingly.
>>> 
>>> Use Travis CI to help catch such issues earlier: check that there are
>>> no untracked files at the end of any build jobs building Git (i.e. the
>>> 64 bit Clang and GCC Linux and OSX build jobs, plus the GETTEXT_POISON
>>> and 32 bit Linux build jobs) or its documentation, and fail the build
>>> job if there are any present.
>>> 
>>> Signed-off-by: SZEDER Gábor <szeder.dev@xxxxxxxxx>
>>> ---
>>> ci/lib-travisci.sh       | 10 ++++++++++
>>> ci/run-linux32-docker.sh |  2 ++
>>> ci/run-tests.sh          |  2 ++
>>> ci/test-documentation.sh |  6 ++++++
>>> 4 files changed, 20 insertions(+)
>>> 
>>> diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh
>>> index 1543b7959..07f27c727 100755
>>> --- a/ci/lib-travisci.sh
>>> +++ b/ci/lib-travisci.sh
>>> @@ -67,6 +67,16 @@ skip_good_tree () {
>>>      exit 0
>>> }
>>> 
>>> +check_unignored_build_artifacts ()
>>> +{
>>> +     ! git ls-files --other --exclude-standard --error-unmatch \
>>> +             -- ':/*' 2>/dev/null ||
>> 
>> What does "-- ':/*'" do?
> 
> It makes the whole thing work :)
> ':/*' is a pattern matching all paths, and '--others --exclude-standard'
> limit the command to list files that are both untracked and unignored.
> '--error-unmatch' causes the command to error out if any of the files
> given on the command line doesn't match anything in the working tree,
> in this case if there are no untracked-unignored files.  Without a path
> given on the cmdline '--error-unmatch' has basically no effect[1].

That was the missing piece. Thank you! I've used the exact command before 
but I've never looked at the exit code. I just assumed that it would
behave like grep if there is no match (as you described in [1])


> In a clean worktree:
> 
>  $ git ls-files --other --exclude-standard --error-unmatch ; echo $?
>  0
>  $ git ls-files --other --exclude-standard --error-unmatch ':/*' ; echo $?
>  error: pathspec ':/*' did not match any file(s) known to git.
>  Did you forget to 'git add'?
>  1
> 
> The disambiguating double-dash is not really necessary, because the :/*
> pattern can't be confused with any --options, but doesn't hurt, either.
> 
>> Plus, why do you redirect stderr?
> 
> To prevent the above error message from appearing in the trace log of a
> successful build.

Makes sense. As I never specified the path, I did never see the error :-)


> [1] - Which makes me think whether we should consider '--error-unmatch'
>      without any paths given on the command line as an error.

Agreed!


- Lars



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux