Commit graph

28 commits

Author SHA1 Message Date
Junio C Hamano
ccbde2c4f4 Merge branch 'da/vs-build-iconv-fix'
Build update.

* da/vs-build-iconv-fix:
  ci(vs-build): stop passing the iconv library location explicitly
2020-12-14 10:21:38 -08:00
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>
2020-12-04 12:03:15 -08:00
Junio C Hamano
719b92eeaf Merge branch 'js/ci-github-set-env'
CI update.

* js/ci-github-set-env:
  ci: avoid using the deprecated `set-env` construct
2020-11-11 13:18:39 -08:00
Junio C Hamano
15486b65d0 Merge branch 'cw/ci-ghwf-check-ws-errors'
Dev support update.

* cw/ci-ghwf-check-ws-errors:
  ci: make the whitespace checker more robust
2020-11-11 13:18:38 -08:00
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>
2020-11-06 22:06:13 -08:00
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>
2020-11-03 12:34:06 -08:00
Junio C Hamano
876511ef61 Merge branch 'js/ci-ghwf-dedup-tests'
GitHub Actions automated test improvement to skip tests on a tree
identical to what has already been tested.

* js/ci-ghwf-dedup-tests:
  ci: make the "skip-if-redundant" check more defensive
  ci: work around old records of GitHub runs
2020-10-30 13:04:24 -07:00
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>
2020-10-12 12:27:12 -07:00
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>
2020-10-12 12:27:10 -07:00
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>
2020-10-09 11:22:05 -07:00
Junio C Hamano
20a00abe35 Merge branch 'js/ci-ghwf-dedup-tests'
The logic to skip testing on the tagged commit and the tag itself
was not quite consistent which led to failure of Windows test
tasks.  It has been revamped to consistently skip revisions that
have already been tested, based on the tree object of the revision.

* js/ci-ghwf-dedup-tests:
  ci: do not skip tagged revisions in GitHub workflows
  ci: skip GitHub workflow runs for already-tested commits/trees
2020-10-08 21:53:26 -07:00
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>
2020-10-08 11:58:37 -07:00
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>
2020-10-07 09:54:53 -07:00
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>
2020-09-02 12:21:45 -07:00
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>
2020-09-02 12:21:41 -07:00
Junio C Hamano
1a753720c3 Merge branch 'am/ci-wsfix'
Aesthetic fix to a CI configuration file.

* am/ci-wsfix:
  ci: fix inconsistent indentation
2020-08-31 15:49:46 -07:00
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>
2020-08-21 12:09:38 -07:00
Junio C Hamano
a30e4c531d Merge branch 'ss/cmake-build'
CMake support to build with MSVC for Windows bypassing the Makefile.

* ss/cmake-build:
  ci: modification of main.yml to use cmake for vs-build job
  cmake: support for building git on windows with msvc and clang.
  cmake: support for building git on windows with mingw
  cmake: support for testing git when building out of the source tree
  cmake: support for testing git with ctest
  cmake: installation support for git
  cmake: generate the shell/perl/python scripts and templates, translations
  Introduce CMake support for configuring Git
2020-08-11 18:04:13 -07:00
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>
2020-06-26 10:08:46 -07:00
Junio C Hamano
fdeb74f372 Merge branch 'es/advertise-contribution-doc'
Doc updates.

* es/advertise-contribution-doc:
  docs: mention MyFirstContribution in more places
2020-06-17 21:54:06 -07:00
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>
2020-06-08 15:12:28 -07:00
Junio C Hamano
55df1a69d7 Merge branch 'js/ci-sdk-download-fix'
Instead of downloading Windows SDK for CI jobs for windows builds
from an external site (wingit.blob.core.windows.net), use the one
created in the windows-build job, to work around quota issues at
the external site.

* js/ci-sdk-download-fix:
  ci: avoid pounding on the poor ci-artifacts container
2020-05-20 08:33:28 -07:00
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>
2020-05-15 08:02:30 -07:00
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>
2020-05-07 12:40:36 -07:00
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>
2020-04-10 10:30:40 -07:00
Đ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>
2020-04-10 10:30:40 -07:00
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>
2019-03-13 11:07:50 +09:00
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>
2017-06-13 08:41:47 -07:00