Re: [PATCH v2 1/2] ci: skip GitHub workflow runs for already-tested commits/trees

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Oct 10, 2020, 07:25 UTC
Message-ID: <20201010072508.GD24813@szeder.dev>
In-Reply-To: <nycvar.QRO.7.76.6.2010091254180.50@tvgsbejvaqbjf.bet>

On Fri, Oct 09, 2020 at 01:13:03PM +0200, Johannes Schindelin wrote:

Show 25 quoted lines

> 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 <johannes.schindelin@gmx.de>
> > >
> > > 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.

Show 5 quoted lines

> 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.