Hi again,
On 19-07-30 21:39:00, Chris Lamb wrote:
> I'm not going to implement this bit just yet until I solve the more
> deeper problem of it, well, not actually caching anything at the
> moment. See previous messages for more background.
As far as I can tell, the cache problem was caused by a
Felix Lechner wrote:
> > caching the result of the former if the tests and some other key files
> > have not changed.
>
> Will it also force an update of the test packages when the build chain
> has changed? It may expose Lintian bugs like #932339.
Whilst my *current* implementation does not
Hi Chris,
On Sat, Jul 20, 2019 at 1:33 PM Chris Lamb wrote:
>
> I've been hacking on this on a Salsa-local fork of Lintian that splits
> the generation of the test packages and the testing itself, crucially
> caching the result of the former if the tests and some other key files
> have not
Hi Georg,
> An alternative might be to use artifacts [1], which work as expected on
> Salsa.
Thanks. Unfortunately, I did investigate using artifacts at first and
whilst they do indeed work on Salsa they are for a different use-case
that does not fit our "re-use from a previous build"
Hi,
I'm not sure if the following is of help, as I didn't saw the involved
code, but:
On 19-07-20 17:28:56, Chris Lamb wrote:
> I have something working except that I am running into a blocker
> whereby the GitLab cache is not seen in subsequent runs.
>
> For example, the cache is being stored
Hi
On Sun, Jul 21, 2019 at 6:28 AM Chris Lamb wrote:
>
> I am very much disposed towards simple and braindead obvious in things
> like this, especially when they hit 90% of the use-case. And then we
> can get back to other stuff...
I realized we are talking about related but different things.
Hi,
On Sun, Jul 21, 2019 at 6:28 AM Chris Lamb wrote:
>
> Felix Lechner wrote:
>
> $ find t/ debian/ -type f | sort | xargs sha1sum | sha1sum | cut -d' ' -f1
That's the same approach I suggested, except I would save the result of
find t/ debian/ -type f | sort | xargs sha1sum
and do so on
Felix Lechner wrote:
> > I've been hacking on this on a Salsa-local fork of Lintian that splits
> > the generation of the test packages and the testing itself, crucially
> > caching the result of the former if the tests and some other key files
> > have not changed.
>
> How do you tell when
On Sat, Jul 20, 2019 at 2:02 PM Felix Lechner
wrote:
>
> This will require a splitting of all 'desc' files
> in the test directories.
Actually, since the values from 'desc' are incorporated in the
completed templates, all 'desc' files can be excluded from the
manifest as well. No splitting is
Hi Chris,
On Sat, Jul 20, 2019 at 1:33 PM Chris Lamb wrote:
>
> I've been hacking on this on a Salsa-local fork of Lintian that splits
> the generation of the test packages and the testing itself, crucially
> caching the result of the former if the tests and some other key files
> have not
Hi all,
> lintian: use GitLab caching of test packages to speed up test suite CI
I've been hacking on this on a Salsa-local fork of Lintian that splits
the generation of the test packages and the testing itself, crucially
caching the result of the former if the tests and some other key files
[changing subject to match updated bug title]
Hi Felix,
> On Mon, Jun 17, 2019 at 4:03 PM Chris Lamb wrote:
> We used filesystem timestamps for a while, but the standard resolution
> (1 sec) was not granular enough. AFAIR, we now generate everything
> every time.
By "filesystem timestamps"
Maybe prove parallel execution can help here (--jobs N)
Le 13/06/2019 à 18:34, Xavier a écrit :
> Maybe prove parallel execution can help here (--jobs N)
Sorry, parallel execution is already set
14 matches
Mail list logo
