kernel/git - git - PowerEL Git System

Tree: 7f46e7ead1

Author	SHA1	Message	Date
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