mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "SZEDER Gábor" <>
To: Johannes Schindelin <>
Cc: Johannes Schindelin via GitGitGadget <>,
Subject: Re: [PATCH v2 1/2] ci: skip GitHub workflow runs for already-tested commits/trees
Date: Sat, 10 Oct 2020 09:25:08 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Oct 09, 2020 at 01:13:03PM +0200, Johannes Schindelin wrote:
> Hi Gábor,
> On Fri, 9 Oct 2020, SZEDER Gábor wrote:
> > On Thu, Oct 08, 2020 at 03:29:34PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > > From: Johannes Schindelin <>
> > >
> > > 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).
> >
> > We have been doing this on Travis CI for a few years now.  Does that
> > approach not work on GitHub actions?  Please explain in the commit
> > message why a different approach is taken here.
> You're not being terribly clear about what exactly "We have been doing".
> Are you referring to the `skip_good_tree()` function that stores
> information in a file in the `good_trees_file`?

Yes, in the commit message you pretty accurately described the exact
purpose of that function.

> If so, no, we cannot do that anywhere else than on Travis because that
> relies on a directory that is somehow shared between runs. And that is a
> feature that only Travis offers as far as I know (and it does not come
> without issues, e.g. when two concurrent runs try to write to the same
> file at the same time).

Every branchname-job combination has its own cache, and while the job
is running it writes to a local copy of its own cache, so concurrent
runs don't seem to be an issue.

> Since this strategy relies on a Travis-only feature that does not work on
> the three other CI services we use (Cirrus CI, Azure DevOps, GitHub
> Actions), I see little point mentioning it in this commit message...

This commit duplicates already existing functionality, so, yes, the
commit message should definitely have explained why that already
existing approach was not suitable for GitHub Actions.

  reply	other threads:[~2020-10-10  7:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 17:17 [PATCH] ci: fix GitHub workflow when on a tagged revision Johannes Schindelin via GitGitGadget
2020-04-24 20:50 ` Junio C Hamano
2020-04-24 21:12   ` Johannes Schindelin
2020-04-24 21:24     ` Junio C Hamano
2020-10-08 15:29 ` [PATCH v2 0/2] Do not skip tagged revisions in the GitHub workflow runs Johannes Schindelin via GitGitGadget
2020-10-08 15:29   ` [PATCH v2 1/2] ci: skip GitHub workflow runs for already-tested commits/trees Johannes Schindelin via GitGitGadget
2020-10-09  7:29     ` SZEDER Gábor
2020-10-09 11:13       ` Johannes Schindelin
2020-10-10  7:25         ` SZEDER Gábor [this message]
2020-10-11 10:28           ` Johannes Schindelin
2020-10-12 16:12             ` Junio C Hamano
2020-10-12 18:57               ` Johannes Schindelin
2020-10-15 17:17                 ` Junio C Hamano
2020-10-15 19:39                   ` Johannes Schindelin
2020-10-08 15:29   ` [PATCH v2 2/2] ci: do not skip tagged revisions in GitHub workflows Johannes Schindelin via GitGitGadget
2020-10-08 21:11   ` [PATCH v2 0/2] Do not skip tagged revisions in the GitHub workflow runs Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).