kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Ævar Arnfjörð Bjarmason	25715419bf	CI: don't run "make test" twice in one job The "linux-clang" and "linux-gcc" jobs both run "make test" twice, but with different environment variables. Running these in sequence seems to have been done to work around some constraint on Travis, see `ae59a4e44f` (travis: run tests with GIT_TEST_SPLIT_INDEX, 2018-01-07). By having these run in parallel we'll get jobs that finish much sooner than they otherwise would have. We can also simplify the control flow in "ci/run-build-and-tests.sh" as a result, since we won't run "make test" twice we don't need to run "make" twice at all, let's default to "make all test" after setting the variables, and then override it to just "all" for the compile-only tests. Add a comment to clarify that new "test" targets should adjust $MAKE_TARGETS rather than being added after the "case/esac". This should avoid future confusion where e.g. the compilation-only "pedantic" target will unexpectedly start running tests. See [1] and [2]. 1. https://lore.kernel.org/git/211122.86ee78yxts.gmgdl@evledraar.gmail.com/ 2. https://lore.kernel.org/git/211123.86ilwjujmd.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Ævar Arnfjörð Bjarmason	707d2f2fe8	CI: use "$runs_on_pool", not "$jobname" to select packages & config Change the setup hooks for the CI to use "$runs_on_pool" for the "$regular" job. Now we won't need as much boilerplate when adding new jobs to the "regular" matrix, see `956d2e4639` (tests: add a test mode for SANITIZE=leak, run it in CI, 2021-09-23) for the last such commit. I.e. now instead of needing to enumerate each jobname when we select packages we can install things depending on the pool we're running in. That we didn't do this dates back to the now gone dependency on Travis CI, but even if we add a new CI target in the future this'll be easier to port over, since we can probably treat "ubuntu-latest" as a stand-in for some recent Linux that can run "apt" commands. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Ævar Arnfjörð Bjarmason	c08bb26010	CI: rename the "Linux32" job to lower-case "linux32" As a follow-up to the preceding commit's shortening of CI job names, rename the only job that starts with an upper-case letter to be consistent with the rest. It was added in `88dedd5e72` (Travis: also test on 32-bit Linux, 2017-03-05). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Ævar Arnfjörð Bjarmason	df7375d772	CI: use shorter names that fit in UX tooltips Change the names used for the GitHub CI workflows to be short enough to (mostly) fit in the pop-up tool-tips that GitHub shows in the commit view. I.e. when mouse-clicking on the passing or failing check-mark next to the commit subject. These names are seemingly truncated to 17-20 characters followed by three dots ("..."). Since a "CI/PR / " prefix is added to them the job names looked like this before (windows-test and vs-test jobs omitted): CI/PR / ci-config (p... CI/PR / windows-buil... CI/PR / vs-build (pu... CI/PR / regular (lin... CI/PR / regular (lin... CI/PR / regular (os... CI/PR / regular (os... CI/PR / regular (lin... CI/PR / regular (lin... CI/PR / dockerized (... CI/PR / dockerized (... CI/PR / dockerized (... CI/PR / static-anal... CI/PR / sparse (pu... CI/PR / documenta... By omitting the "/PR" from the top-level name, and pushing the $jobname to the front we'll now instead get: CI / config (push) CI / win build (push... CI / win+VS build (... CI / linux-clang (ub... CI / linux-gcc (ubun... CI / osx-clang (osx)... CI / osx-gcc (osx) (... CI / linux-gcc-defau... CI / linux-leaks (ub... CI / linux-musl (alp... CI / Linux32 (daald/... CI / pedantic (fedor... CI / static-analysis... CI / sparse (push)... CI / documentation We then have no truncation in the expanded view. See [1] for how it looked before, [2] for a currently visible CI run using this commit, and [3] for the GitHub workflow syntax involved being changed here. Let's also use the existing "pool" field as before. It's occasionally useful to know we're running on say ubuntu v.s. fedora. The "-latest" suffix is useful to some[4], and since it's now at the end it doesn't hurt readability in the short view compared to saying "ubuntu" or "macos". 1. https://github.com/git/git/tree/master/ 2. https://github.com/avar/git/tree/avar/ci-rm-travis-cleanup-ci-names-3 3. https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions 3. https://lore.kernel.org/git/d9b07ca5-b58d-a535-d25b-85d7f12e6295@github.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Hans Krentel (hakre)	bf5b83fd8a	ci(check-whitespace): update stale file top comments Earlier `a066a90d` (ci(check-whitespace): restrict to the intended commits, 2021-07-14) changed the check-whitespace task to stop using a shallow clone, and `cc003621` (ci(check-whitespace): stop requiring a read/write token, 2021-07-14) changed the way how the errors the task discovered is signaled back to the user. They however forgot to update the comment that outlines what is done in the task. Correct them. Signed-off-by: Hans Krentel (hakre) <hanskrentel@yahoo.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Johannes Schindelin	0e7696c64d	ci: disallow directional formatting As described in https://trojansource.codes/trojan-source.pdf, it is possible to abuse directional formatting (a feature of Unicode) to deceive human readers into interpreting code differently from compilers. For example, an "if ()" expression could be enclosed in a comment, but rendered as if it was outside of that comment. In effect, this could fool a reviewer into misinterpreting the code flow as benign when it is not. It is highly unlikely that Git's source code wants to contain such directional formatting in the first place, so let's just disallow it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Johannes Schindelin	7491ef6198	ci(windows): ensure that we do not pick up random executables On the Windows build agents, a lot of programs are installed, and added to the PATH automatically. One such program is Git for Windows, and due to the way it is set up, unfortunately its copy of `gpg.exe` is also reachable via the PATH. This usually does not pose any problems. To the contrary, it even allows us to test the GPG parts of Git's test suite even if `gpg.exe` is not delivered as part of `git-sdk-64-minimal`, the minimal subset of Git for Windows' SDK that we use in the CI builds to compile Git. However, every once in a while we build a new MSYS2 runtime, which means that there is a mismatch between the copy in `git-sdk-64-minimal` and the copy in C:\Program Files\Git\usr\bin. When that happens we hit the dreaded problem where only one `msys-2.0.dll` is expected to be in the PATH, and things start to fail. Let's avoid all of this by restricting the PATH to the minimal set. This is actually done by `git-sdk-64-minimal`'s `/etc/profile`, and we just have to source this file manually (one would expect that it is sourced automatically, but the Bash steps in Azure Pipelines/GitHub workflows are explicitly run using `--noprofile`, hence the need for doing this explicitly). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Ævar Arnfjörð Bjarmason	956d2e4639	tests: add a test mode for SANITIZE=leak, run it in CI While git can be compiled with SANITIZE=leak, we have not run regression tests under that mode. Memory leaks have only been fixed as one-offs without structured regression testing. This change adds CI testing for it. We'll now build and small set of whitelisted t00.sh tests under Linux with a new job called "linux-leaks". The CI target uses a new GIT_TEST_PASSING_SANITIZE_LEAK=true test mode. When running in that mode, we'll assert that we were compiled with SANITIZE=leak. We'll then skip all tests, except those that we've opted-in by setting "TEST_PASSES_SANITIZE_LEAK=true". A test setting "TEST_PASSES_SANITIZE_LEAK=true" setting can in turn make use of the "SANITIZE_LEAK" prerequisite, should they wish to selectively skip tests even under "GIT_TEST_PASSING_SANITIZE_LEAK=true". In the preceding commit we started doing this in "t0004-unwritable.sh" under SANITIZE=leak, now it'll combine nicely with "GIT_TEST_PASSING_SANITIZE_LEAK=true". This is how tests that don't set "TEST_PASSES_SANITIZE_LEAK=true" will be skipped under GIT_TEST_PASSING_SANITIZE_LEAK=true: $ GIT_TEST_PASSING_SANITIZE_LEAK=true ./t0001-init.sh 1..0 # SKIP skip all tests in t0001 under SANITIZE=leak, TEST_PASSES_SANITIZE_LEAK not set The intent is to add more TEST_PASSES_SANITIZE_LEAK=true annotations as follow-up change, but let's start small to begin with. In ci/run-build-and-tests.sh we make use of the default "" case to run "make test" without any GIT_TEST_* modes. SANITIZE=leak is known to fail in combination with GIT_TEST_SPLIT_INDEX=true in t0016-oidmap.sh, and we're likely to have other such failures in various GIT_TEST_* modes. Let's focus on getting the base tests passing, we can expand coverage to GIT_TEST_* modes later. It would also be possible to implement a more lightweight version of this by only relying on setting "LSAN_OPTIONS". See <YS9OT/pn5rRK9cGB@coredump.intra.peff.net>[1] and <YS9ZIDpANfsh7N+S@coredump.intra.peff.net>[2] for a discussion of that. I've opted for this approach of adding a GIT_TEST_* mode instead because it's consistent with how we handle other special test modes. Being able to add a "!SANITIZE_LEAK" prerequisite and calling "test_done" early if it isn't satisfied also means that we can more incrementally add regression tests without being forced to fix widespread and hard-to-fix leaks at the same time. We have tests that do simple checking of some tool we're interested in, but later on in the script might be stressing trace2, or common sources of leaks like "git log" in combination with the tool (e.g. the commit-graph tests). To be clear having a prerequisite could also be accomplished by using "LSAN_OPTIONS" directly. On the topic of "LSAN_OPTIONS": It would be nice to have a mode to aggregate all failures in our various scripts, see [2] for a start at doing that which sets "log_path" in "LSAN_OPTIONS". I've punted on that for now, it can be added later. As of writing this we've got major regressions between master..seen, i.e. the t000*.sh tests and more fixed since `31f9acf9ce` (Merge branch 'ah/plugleaks', 2021-08-04) have regressed recently. See the discussion at <87czsv2idy.fsf@evledraar.gmail.com>[3] about the lack of this sort of test mode, and `0e5bba53af` (add UNLEAK annotation for reducing leak false positives, 2017-09-08) for the initial addition of SANITIZE=leak. See also `09595ab381` (Merge branch 'jk/leak-checkers', 2017-09-19), `7782066f67` (Merge branch 'jk/apache-lsan', 2019-05-19) and the recent `936e58851a` (Merge branch 'ah/plugleaks', 2021-05-07) for some of the past history of "one-off" SANITIZE=leak (and more) fixes. As noted in [5] we can't support this on OSX yet until Clang 14 is released, at that point we'll probably want to resurrect that "osx-leaks" job. 1. https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer 2. https://lore.kernel.org/git/YS9OT%2Fpn5rRK9cGB@coredump.intra.peff.net/ 3. https://lore.kernel.org/git/87czsv2idy.fsf@evledraar.gmail.com/ 4. https://lore.kernel.org/git/YS9ZIDpANfsh7N+S@coredump.intra.peff.net/ 5. https://lore.kernel.org/git/20210916035603.76369-1-carenas@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Jiang Xin	a788d31931	ci: new github-action for git-l10n code review The repository of git-l10n is a fork of "git/git" on GitHub, and uses GitHub pull request for code review. A helper program "git-po-helper" can be used to check typos in ".po" files, validate syntax, and check commit messages. It would be convenient to integrate this helper program to CI and add comments in pull request. The new github-action workflow will be enabled for l10n related operations, such as: * Operations on a repository named as "git-po", such as a repository forked from "git-l10n/git-po". * Push to a branch that contains "l10n" in the name. * Pull request from a remote branch which has "l10n" in the name, such as: "l10n/fix-fuzzy-translations". The new l10n workflow listens to two types of github events: on: [push, pull_request_target] The reason we use "pull_request_target" instead of "pull_request" is that pull requests from forks receive a read-only GITHUB_TOKEN and workflows cannot write comments back to pull requests for security reasons. GitHub provides a "pull_request_target" event to resolve security risks by checking out the base commit from the target repository, and provide write permissions for the workflow. By default, administrators can set strict permissions for workflows. The following code is used to modify the permissions for the GITHUB_TOKEN and grant write permission in order to create comments in pull-requests. permissions: pull-requests: write This workflow will scan commits one by one. If a commit does not look like a l10n commit (no file in "po/" has been changed), the scan process will stop immediately. For a "push" event, no error will be reported because it is normal to push non-l10n commits merged from upstream. But for the "pull_request_target" event, errors will be reported. For this reason, additional option is provided for "git-po-helper". git-po-helper check-commits \ --github-action-event="${{ github.event_name }}" -- \ <base>..<head> The output messages of "git-po-helper" contain color codes not only for console, but also for logfile. This is because "git-po-helper" uses a package named "logrus" for logging, and I use an additional option "ForceColor" to initialize "logrus" to print messages in a user-friendly format in logfile output. These color codes help produce beautiful output for the log of workflow, but they must be stripped off when creating comments for pull requests. E.g.: perl -pe 's/\e\[[0-9;]*m//g' git-po-helper.out "git-po-helper" may generate two kinds of suggestions, errors and warnings. All the errors and warnings will be reported in the log of the l10n workflow. However, warnings in the log of the workflow for a successfully running "git-po-helper" can easily be ignored by users. For the "pull_request_target" event, this issue is resolved by creating an additional comment in the pull request. A l10n contributor should try to fix all the errors, and should pay attention to the warnings. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Johannes Schindelin	aa4df107e7	tests: stop testing `git rebase --preserve-merges` This backend has been deprecated in favor of `git rebase --rebase-merges`. In preparation for dropping it, let's remove all the regression tests that would need it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	3 years ago
Carlo Marcelo Arenas Belón	3cf9bb36bf	ci: use upload-artifacts v1 for dockerized jobs `e9f79acb28` (ci: upgrade to using actions/{up,down}load-artifacts v2, 2021-06-23) changed all calls to that action from v1 to v2, but there is still an open bug[1] that affects all nodejs actions and prevents its use in 32-bit linux (as used by the Linux32 container) move all dockerized jobs to use v1 that was built in C# and therefore doesn't have this problem, which will otherwise manifest with confusing messages like: /usr/bin/docker exec 0285adacc4536b7cd962079c46f85fa05a71e66d7905b5e4b9b1a0e8b305722a sh -c "cat /etc/*release \| grep ^ID" OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: no such file or directory: unknown [1] https://github.com/actions/runner/issues/1011 Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Carlo Marcelo Arenas Belón	cebead1ebf	ci: run a pedantic build as part of the GitHub workflow similar to the recently added sparse task, it is nice to know as early as possible. add a dockerized build using fedora (that usually has the latest gcc) to be ahead of the curve and avoid older ISO C issues at the same time. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Jeff King	27f45ccf33	ci/install-dependencies: handle "sparse" job package installs This just matches the style/location of the package installation for other jobs. There should be no functional change. I did flip the order of the options and command-name ("-y update" instead of "update -y") for consistency with other lines in the same file. Note also that we have to reorder the dependency install with the "checkout" action, so that we actually have the "ci" scripts available. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Jeff King	8231c841ff	ci: run "apt-get update" before "apt-get install" The "sparse" workflow runs "apt-get install" to pick up a few necessary packages. But it needs to run "apt-get update" first, or it risks trying to download an old package version that no longer exists. And in fact this happens now, with output like: 2021-07-26T17:40:51.2551880Z E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl4-openssl-dev_7.68.0-1ubuntu2.5_amd64.deb 404 Not Found [IP: 52.147.219.192 80] 2021-07-26T17:40:51.2554304Z E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Our other ci jobs don't suffer from this; they rely on scripts in ci/, and ci/install-dependencies does the appropriate "apt-get update". Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	a066a90db6	ci(check-whitespace): restrict to the intended commits During a run of the `check-whitespace` we want to verify that the commits introduced in the Pull Request have no whitespace issues. We only want to look at those commits, not the upstream commits (because the contributor cannot do anything about the latter). However, by using the `-<count>` form in `git log --check`, we run the risk of looking at the wrong commits. The reason is that the `actions/checkout` step does _not_ check out the tip commit of the Pull Request's branch: Instead, it checks out a merge commit that merges that branch into the target branch. For that reason, we already adjust the commit count by incrementing it, but that is not enough: if the upstream branch has newer commits, they are traversed _first_. And obviously we will then miss some of the commits that we _actually_ wanted to look at. Therefore, let's be careful to stop assuming a linear, up to date commit topology in the contributed commits, and instead specify the correct commit range. Unfortunately, this means that we no longer can rely on a shallow clone: There is no way of knowing just how many commits the upstream branch advanced after the commit from which the PR branch branched off. So let's just go with a full clone instead, and be safe rather than sorry (if we have "too shallow" a situation, a commit range `@{u}..` may very well include a shallow commit itself, and the output of `git show --check <shallow>` is _not_ pretty). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	cc00362125	ci(check-whitespace): stop requiring a read/write token As part of some recent security tightening, GitHub introduced the ability to configure GitHub workflows to be run with a read-only token. This is much more secure, in particular when working in a public repository: While the regular read/write token might be restricted to writing to the current branch, it is not necessarily restricted to access only the current Pull Request. However, the `check-whitespace` workflow threw a wrench into this plan: it _requires_ write access (because it wants to add a PR comment in case of a whitespace issue). Let's just skip that PR comment. The user can always click through to the actual error, even if it is slightly less convenient. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	e61059660c	ci: run `make sparse` as part of the GitHub workflow Occasionally we receive reviews after patches were integrated, where `sparse` (https://sparse.docs.kernel.org/en/latest/ has more information on that project) identified problems such as file-local variables or functions being declared as global. By running `sparse` as part of our Continuous Integration, we can catch such things much earlier. Even better: developers who activated GitHub Actions on their forks can catch such issues before even sending their patches to the Git mailing list. This addresses https://github.com/gitgitgadget/git/issues/345 Note: Not even Ubuntu 20.04 ships with a new enough version of `sparse` to accommodate Git's needs. The symptom looks like this: add-interactive.c:537:51: error: Using plain integer as NULL pointer To counter that, we download and install the custom-built `sparse` package from the Azure Pipeline that we specifically created to address this issue. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	0dc787a9f2	ci: accelerate the checkout By upgrading from v1 to v2 of `actions/checkout`, we avoid fetching all the tags and the complete history: v2 only fetches one revision by default. This should make things a lot faster. Note that `actions/checkout@v2` seems to be incompatible with running in containers: https://github.com/actions/checkout/issues/151. Therefore, we stick with v1 there. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Dennis Ameling	9ab0b66129	ci (vs-build): build with NO_GETTEXT We already build Git for Windows with `NO_GETTEXT` when compiling with GCC. Let's do the same with Visual C, too. Note that we do not technically _need_ to pass `NO_GETTEXT` explicitly in that `make artifacts-tar` invocation because we do this while `MSVC` is set (which will set `uname_S := Windows`, which in turn will set `NO_GETTEXT = YesPlease`). But it is definitely nicer to be explicit here. Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Helped-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	d681d0dc3a	ci (windows): transfer also the Git-tracked files to the test jobs Git's test suite is excruciatingly slow on Windows, mainly due to the fact that it executes a lot of shell script code, and that's simply not native to Windows. To help with that, we established the pattern where the artifacts are first built in one job, and then multiple test jobs run in parallel using the artifacts built in the first job. We take pains in transferring only the build outputs, and letting `actions/checkout` fill in the rest of the files. One major downside of that strategy is that the test jobs might fail to check out the intended revision (e.g. because the branch has been updated while the build was running, as is frequently the case with the `seen` branch). Let's transfer also the files tracked by Git, and skip the checkout step in the test jobs. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	e9f79acb28	ci: upgrade to using actions/{up,down}load-artifacts v2 The GitHub Actions to upload/download workflow artifacts saw a major upgrade since Git's GitHub workflow was established. Let's use it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	abb2b389f7	ci (vs-build): use `cmd` to copy the DLLs, not `powershell` We use a `.bat` script to copy the DLLs in the `vs-build` job, and those type of scripts are native to CMD, not to PowerShell. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	0eb6c189a3	ci: use the new GitHub Action to download git-sdk-64-minimal In our continuous builds, Windows is the odd cookie that requires a complete development environment to be downloaded because there is no suitable one installed by default on Windows. Side note: technically, there _is_ a development environment present in GitHub Actions' build agents: MSYS2. But it differs from Git for Windows' SDK in subtle points, unfortunately enough so to prevent Git's test suite from running without failures. Traditionally, we support downloading this environment (which we nicknamed `git-sdk-64-minimal`) via a PowerShell scriptlet that accesses the build artifacts of a dedicated Azure Pipeline (which packages a tiny subset of the full Git for Windows SDK, containing just enough to build Git and run its test suite). This PowerShell script is unfortunately not very robust and sometimes fails due to network issues. Of course, we could add code to detect that situation, wait a little, try again, if it fails again wait a little longer, lather, rinse and repeat. Instead of doing all of this in Git's own `.github/workflows/`, though, let's offload this logic to the new GitHub Action at https://github.com/marketplace/actions/setup-git-for-windows-sdk This Action not only downloads and extracts git-sdk-64-minimal _outside_ the worktree (making it no longer necessary to meddle with `.gitignore` or `.git/info/exclude`), it also adds the `bash.exe` to the `PATH` and sets the environment variable `MSYSTEM` (an implementation detail that Git's workflow should never have needed to know about). This allows us to convert all those funny PowerShell tasks that wanted to call git-sdk-64-minimal's `bash.exe`: they all are now regular `bash` scriptlets. This finally lets us get rid of the funny quoting and escaping where we had to pay attention not only to quote and escape the Bash scriptlets properly, but also to add a second level of escaping (with backslashes for double quotes and backticks for dollar signs) to stop PowerShell from doing unintended things. Further, this Action uses a fast caching strategy native to GitHub Actions that should accelerate the download across CI runs: git-sdk-64-minimal is usually updated once per 24h, and needs to be cached only once within that period. Caching it (unfortunately only on a per-branch basis) speeds up the download step, and makes it much more robust at the same time by virtue of accessing a cache location that is closer in the network topology. With this we can drop the home-rolled caching where we try to accelerate the test phase by uploading git-sdk-64-minimal as a workflow artifact after using it to build Git, and then download it as workflow artifact in the test phase. Even better: the `vs-test` job no longer needs to depend on the `windows-build` job. The only reason it depended on it was to ensure that the `git-sdk-64-minimal` workflow artifact was available. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Dennis Ameling	958a5f5dfe	cmake(install): include vcpkg dlls Our CMake configuration generates not only build definitions, but also install definitions: After building Git using `msbuild git.sln`, the built artifacts can be installed via `msbuild INSTALL.vcxproj`. To specify _where_ the files should be installed, the `-DCMAKE_INSTALL_PREFIX=<path>` option can be used when running CMake. However, this process would really only install the files that were just built. On Windows, we need more than that: We also need the `.dll` files of the dependencies (such as libcurl). The `vcpkg` ecosystem, which we use to obtain those dependencies, can be asked to install said `.dll` files really easily, so let's do that. This requires more than just the built `vcpkg` artifacts in the CI build definition; We now clone the `vcpkg` repository so that the relevant CMake scripts are available, in particular the ones related to defining the toolchain. Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Taylor Blau	d051ed77ee	.github/workflows/main.yml: run static-analysis on bionic GitHub Actions is transitioning workflow steps that run on 'ubuntu-latest' from 18.04 to 20.04 [1]. This works fine in all steps except the static-analysis one, since Coccinelle isn't available on Ubuntu focal (it is only available in the universe suite). Until Coccinelle can be installed from 20.04's main suite, pin the static-analysis build to run on 18.04, where it can be installed by default. [1]: https://github.com/actions/virtual-environments/issues/1816 Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Philippe Blain	2b0e14f640	ci: do not cancel all jobs of a matrix if one fails The CI/PR GitHub Actions workflow uses the 'matrix' strategy for the "windows-test", "vs-test", "regular" and "dockerized" jobs. The default behaviour of GitHub Actions is to cancel all in-progress jobs in a matrix if one of the job of the matrix fails [1]. This is not ideal as a failure early in a job, like during installation of the build/test dependencies on a specific platform, leads to the cancellation of all other jobs in the matrix. Set the 'fail-fast' variable to 'false' for all four matrix jobs in the workflow. [1] https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Ævar Arnfjörð Bjarmason	6c280b4142	ci: remove GETTEXT_POISON jobs A subsequent commit will remove GETTEXT_POISON entirely, let's start by removing the CI jobs that enable the option. We cannot just remove the job because the CI is implicitly depending on the "poison" job being a sort of "default" job in the sense that it's the job that was otherwise run with the default compiler, no other GIT_TEST_* options etc. So let's keep it under the name "linux-gcc-default". This means we can remove the initial "make test" from the "linux-gcc" job (it does another one after setting a bunch of GIT_TEST_* variables). I'm not doing that because it would conflict with the in-flight `334afbc76f` (tests: mark tests relying on the current default for `init.defaultBranch`, 2020-11-18) (currently on the "seen" branch, so the SHA-1 will almost definitely change). It's going to use that "make test" again for different reasons, so let's preserve it for now. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Dennis Ameling	e66590348a	ci(vs-build): stop passing the iconv library location explicitly Something changed in `vcpkg` (which we use in our Visual C++ build to provide the dependencies such as libcurl) and our `vs-build` job started failing in CI. The reason is that we had a work-around in place to help CMake find iconv, and this work-around is neither needed nor does it work anymore. For the full discussion with the vcpkg project, see this comment: https://github.com/microsoft/vcpkg/issues/14780#issuecomment-735368280 Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	cac42e471a	ci: avoid using the deprecated `set-env` construct The `set-env` construct was deprecated as of the announcement in https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/ Let's use the recommended alternative instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	cba2504d3d	ci: make the whitespace checker more robust In `32c83afc2c` (ci: github action - add check for whitespace errors, 2020-09-22), we introduced a GitHub workflow that automatically checks Pull Requests for whitespace problems. However, when affected lines contain one or more double quote characters, this workflow failed to attach the informative comment because the Javascript snippet incorrectly interpreted these quotes instead of using the `git log` output as-is. Let's fix that. While at it, let's `await` the result of the `createComment()` function. Finally, we enclose the log in the comment with ```...``` to avoid having the diff marker be misinterpreted as an enumeration bullet. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	d6d6683797	ci: make the "skip-if-redundant" check more defensive In `7d78d5fc1a` (ci: skip GitHub workflow runs for already-tested commits/trees, 2020-10-08), we added a check that determines whether there is already a workflow run for the given commit (or at least tree), and if found, skips the current run. We just worked around an issue with this check where older runs might unexpectedly miss the `head_commit` attribute. Let's be even more defensive by catching all kinds of exceptions, logging them as warnings, and continue the run without skipping it (after all, if the check fails, we _want_ to continue with the run). This commit is best viewed with the diff option `-w` because it increases the indentation level of the GitHub Action script by two spaces, surrounding it by a `try ... catch` construct. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	d0ff1a3cbc	ci: work around old records of GitHub runs Apparently older GitHub runs at least _sometimes_ lack information about the `head_commit` (and therefore the `ci-config` check will fail with "TypeError: Cannot read property 'tree_id' of null") in the check added in `7d78d5fc1a` (ci: skip GitHub workflow runs for already-tested commits/trees, 2020-10-08). Let's work around this by adding a defensive condition. Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Chris. Webster	32c83afc2c	ci: github action - add check for whitespace errors Not all developers are aware of `git diff --check` to warn about whitespace issues. Running a check when a pull request is opened or updated can save time for reviewers and the submitter. A GitHub workflow will run when a pull request is created or the contents are updated to check the patch series. A pull request provides the necessary information (number of commits) to only check the patch series. To ensure the developer is aware of any issues, a comment will be added to the pull request with the check errors. Signed-off-by: Chris. Webster <chris@webstech.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	7d78d5fc1a	ci: skip GitHub workflow runs for already-tested commits/trees When pushing a commit that has already passed a CI or PR build successfully, it makes sense to save some energy and time and skip the new build. Let's teach our GitHub workflow to do that. For good measure, we also compare the tree ID, which is what we actually test (the commit ID might have changed due to a reworded commit message, which should not affect the outcome of the run). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	17c13069b4	GitHub workflow: automatically follow minor updates of setup-msbuild It is the custom to follow minor updates of GitHub Actions automatically, by using the suffix `@v1`. Actions' maintainers will then update that `v1` ref to point to the newest. However, for `microsoft/setup-msbuild`, `889cacb689` (ci: configure GitHub Actions for CI/PR, 2020-04-11) uses a very specific `@v1.0.0` suffix. In this instance, that is a problem: should `setup-msbuild` release a new version that intends to fix a critical bug, we won't know it, and we won't use it. Such a scenario is not theoretical. It is happening right now: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands Let's simplify our setup, allowing us to benefit from automatically using the newest v1.x. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	2fcf7a8c65	ci: avoid ugly "failure" in the `ci-config` job In the common case where users have _not_ pushed a `ci-config` branch to configure which branches should be included in the GitHub workflow runs, there is a big fat ugly annotation about a failure in the run's log: X Check failure on line 1 in .github @github-actions github-actions / ci-config .github#L1 Process completed with exit code 128. The reason is that the `ci-config` job tries to clone that `ci-config` branch, and even if it is configured to continue on error, the annotation is displayed, and it is distracting. Let's just handle this on the shell script level, so that the job's step is not marked as a failure. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	b01aff8c1c	ci: fix indentation of the `ci-config` job The section added in `e76eec3554` (ci: allow per-branch config for GitHub Actions, 2020-05-07) contains a `&&`-chain that connects several commands. The first command is actually so long that it stretches over multiple lines, and as per usual, the continuation lines are indented one more level than the first. However, the subsequent commands in the `&&`-chain were also indented one more level than the first command, which was almost certainly unintended. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Adrian Moennich	055747cd75	ci: fix inconsistent indentation While YAML allows different indentation styles as long as each block is consistent, it is rather unusual to mix different indentations in a single file. Adjust to use two-space indentation everywhere. Signed-off-by: Adrian Moennich <adrian@planetcoding.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Sibi Siddharthan	4c2c38e800	ci: modification of main.yml to use cmake for vs-build job Teach .github/workflows/main.yml to use CMake for VS builds. Modified the vs-test step to match windows-test step. This speeds up the vs-test. Calling git-cmd from powershell and then calling git-bash to perform the tests slows things down(factor of about 6). So git-bash is directly called from powershell to perform the tests using prove. NOTE: Since GitHub keeps the same directory for each job (with respect to path) absolute paths are used in the bin-wrapper scripts. GitHub has switched to CMake 3.17.1 which changed the behaviour of FindCURL module. An extra definition (-DCURL_NO_CURL_CMAKE=ON) has been added to revert to the old behaviour. In the configuration phase CMake looks for the required libraries for building git (eg zlib,libiconv). So we extract the libraries before we configure. To check for ICONV_OMITS_BOM libiconv.dll needs to be in the working directory of script or path. So we copy the dlls before we configure. Signed-off-by: Sibi Siddharthan <sibisiddharthan.github@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Emily Shaffer	b75a219904	docs: mention MyFirstContribution in more places While the MyFirstContribution guide exists and has received some use and positive reviews, it is still not as discoverable as it could be. Add a reference to it from the GitHub pull request template, where many brand-new contributors may look. Also add a reference to it in SubmittingPatches, which is the central source of guidance for patch contribution. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Reviewed-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	857341c1b7	ci: avoid pounding on the poor ci-artifacts container When this developer tested how the git-sdk-64-minimal artifact could be served to all the GitHub workflow runs that need it, Azure Blobs looked like a pretty good choice: it is reliable, fast and we already use it in Git for Windows to serve components like OpenSSL, cURL, etc It came as an unpleasant surprise just _how many_ times this artifact was downloaded. It exploded the bandwidth to a point where the free tier would no longer be enough, threatening to block other, essential Git for Windows services. Let's switch back to using the Build Artifacts of our trusty Azure Pipeline for the time being. To avoid unnecessary hammering of the Azure Pipeline artifacts, we use the GitHub Action `actions/upload-artifact` in the `windows-build` job and the GitHub Action `actions/download-artifact` in the `windows-test` and `vs-test` jobs (the latter now depends on `windows-build` for that reason, too). Helped-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	e76eec3554	ci: allow per-branch config for GitHub Actions Depending on the workflows of individual developers, it can either be convenient or annoying that our GitHub Actions CI jobs are run on every branch. As an example of annoying: if you carry many half-finished work-in-progress branches and rebase them frequently against master, you'd get tons of failure reports that aren't interesting (not to mention the wasted CPU). This commit adds a new job which checks a special branch within the repository for CI config, and then runs a shell script it finds there to decide whether to skip the rest of the tests. The default will continue to run tests for all refs if that branch or script is missing. There have been a few alternatives discussed: One option is to carry information in the commit itself about whether it should be tested, either in the tree itself (changing the workflow YAML file) or in the commit message (a "[skip ci]" flag or similar). But these are frustrating and error-prone to use: - you have to manually apply them to each branch that you want to mark - it's easy for them to leak into other workflows, like emailing patches We could likewise try to get some information from the branch name. But that leads to debates about whether the default should be "off" or "on", and overriding still ends up somewhat awkward. If we default to "on", you have to remember to name your branches appropriately to skip CI. And if "off", you end up having to contort your branch names or duplicate your pushes with an extra refspec. By comparison, this commit's solution lets you specify your config once and forget about it, and all of the data is off in its own ref, where it can be changed by individual forks without touching the main tree. There were a few design decisions that came out of on-list discussion. I'll summarize here: - we could use GitHub's API to retrieve the config ref, rather than a real checkout (and then just operate on it via some javascript). We still have to spin up a VM and contact GitHub over the network from it either way, so it ends up not being much faster. I opted to go with shell to keep things similar to our other tools (and really could implement allow-refs in any language you want). This also makes it easy to test your script locally, and to modify it within the context of a normal git.git tree. - we could keep the well-known refname out of refs/heads/ to avoid cluttering the branch namespace. But that makes it awkward to manipulate. By contrast, you can just "git checkout ci-config" to make changes. - we could assume the ci-config ref has nothing in it except config (i.e., a branch unrelated to the rest of git.git). But dealing with orphan branches is awkward. Instead, we'll do our best to efficiently check out only the ci/config directory using a shallow partial clone, which allows your ci-config branch to be just a normal branch, with your config changes on top. - we could provide a simpler interface, like a static list of ref patterns. But we can't get out of spinning up a whole VM anyway, so we might as well use that feature to make the config as flexible as possible. If we add more config, we should be able to reuse our partial-clone to set more outputs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	f72f328bc5	ci: let GitHub Actions upload failed tests' directories Arguably, CI builds' most important task is to not only identify regressions, but to make it as easy as possible to investigate what went wrong. In that light, we will want to provide users with a way to inspect the tests' output as well as the corresponding directories. This commit adds build steps that are only executed when tests failed, uploading the relevant information as build artifacts. These artifacts can then be downloaded by interested parties to diagnose the failures more efficiently. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Đoàn Trần Công Danh	889cacb689	ci: configure GitHub Actions for CI/PR This patch adds CI builds via GitHub Actions. While the underlying technology is at least _very_ similar to that of Azure Pipelines, GitHub Actions are much easier to set up than Azure Pipelines: - no need to install a GitHub App, - no need to set up an Azure DevOps account, - all you need to do is push to your fork on GitHub. Therefore, it makes a lot of sense for us to have a working GitHub Actions setup. While copy/editing `azure-pipelines.yml` into `.github/workflows/main.yml`, we also use the opportunity to accelerate the step that sets up a minimal subset of Git for Windows' SDK in the Windows-build job: - we now download a `.tar.xz` stored in Azure Blobs and extract it simultaneously by calling `curl` and piping the result to `tar`, - decompressing via `xz`, - all three utilities are installed together with Git for Windows At the same time, we also make use of the matrix build feature, which reduces the amount of repeated text by quite a bit. Also, we do away with the parts that try to mount a file share on which `prove` can store data between runs. It is just too complicated to set up, and most times the tree changes anyway, so there is little return on investment there. Initial-patch-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	c3a7dd70c4	point pull requesters to GitGitGadget In the contributing guide and PR template seen by people who open pull requests on GitHub, we mention the submitGit tool, which gives an alternative to figuring out the mailing list. These days we also have the similar GitGitGadget tool, and we should make it clear that this is also an option. We could continue to mention _both_ tools, but it's probably better to pick one in order to avoid overwhelming the user with choice. After all, one of the purposes here is to reduce friction for first-time or infrequent contributors. And there are a few reasons to prefer GGG: 1. submitGit seems to still have a few rough edges. E.g., it doesn't munge timestamps to help threaded mail readers handled out-of-order delivery. 2. Subjectively, GGG seems to be more commonly used on the list these days, especially by list regulars. 3. GGG seems to be under more active development (likely related to point 2). So let's actually swap out submitGit for GGG. While we're there, let's put another link to the GGG page in the PR template, because that's where users who are learning about it for the first time will want to go to read more. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Lars Schneider	0b1bb0c032	Configure Git contribution guidelines for github.com Many open source projects use github.com for their contribution process. Although we mirror the Git core repository to github.com [1] we do not use any other github.com service. This is unknown/unexpected to a number of (potential) contributors and consequently they create Pull Requests against our mirror with their contributions. These Pull Requests become stale. This is frustrating to them as they think we ignore them and it is also unsatisfactory for us as we miss potential code improvements and/or new contributors. GitHub contribution guidelines and a GitHub Pull Request template that is visible to every Pull Request creator can be configured with special files in a Git repository [2]. Let's make use of this! [1] https://github.com/git/git [2] https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/ Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago

1 2

69 Commits (c6e19e47a60c0174f805db8e1624db38ff889523)