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

On Tue, Jan 2, 2018 at 8:40 PM, Lars Schneider [off-list ref] wrote:

quoted

On 31 Dec 2017, at 17:02, SZEDER Gábor [off-list ref] 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 <redacted>
---
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].

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.


[1] - Which makes me think whether we should consider '--error-unmatch'
      without any paths given on the command line as an error.
      On a related note: that error message doesn't seem to make much
      sense with '--other'...