summaryrefslogtreecommitdiff
path: root/.github
AgeCommit message (Collapse)AuthorFilesLines
2020-08-11Merge branch 'ss/cmake-build'Libravatar Junio C Hamano1-15/+24
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-06-26ci: modification of main.yml to use cmake for vs-build jobLibravatar Sibi Siddharthan1-15/+24
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-17Merge branch 'es/advertise-contribution-doc'Libravatar Junio C Hamano1-0/+3
Doc updates. * es/advertise-contribution-doc: docs: mention MyFirstContribution in more places
2020-06-08docs: mention MyFirstContribution in more placesLibravatar Emily Shaffer1-0/+3
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-05-20Merge branch 'js/ci-sdk-download-fix'Libravatar Junio C Hamano1-11/+44
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-15ci: avoid pounding on the poor ci-artifacts containerLibravatar Johannes Schindelin1-11/+44
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-07ci: allow per-branch config for GitHub ActionsLibravatar Jeff King1-0/+42
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-04-10ci: let GitHub Actions upload failed tests' directoriesLibravatar Johannes Schindelin1-0/+18
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-10ci: configure GitHub Actions for CI/PRLibravatar Đoàn Trần Công Danh1-0/+212
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>
2019-03-13point pull requesters to GitGitGadgetLibravatar Jeff King2-3/+3
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>
2017-06-13Configure Git contribution guidelines for github.comLibravatar Lars Schneider2-0/+26
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>