On Fri, Jan 08, 2021 at 12:06:01PM +0100, Thomas Huth wrote:
> On 08/01/2021 11.16, Daniel P. Berrangé wrote:
>
> > IOW, despite travis giving us non-x86 builders, it is doomed to be
> > unusuable, unless we can convince them to give us a *massively*
> > larger free credit allowance on the qemu
On 08/01/2021 11.16, Daniel P. Berrangé wrote:
IOW, despite travis giving us non-x86 builders, it is doomed to be
unusuable, unless we can convince them to give us a *massively*
larger free credit allowance on the qemu account.
I think convincing them to do this will be very hard. I've tried
On Thu, Jan 07, 2021 at 08:23:49PM +0100, Paolo Bonzini wrote:
> Il gio 7 gen 2021, 20:05 Thomas Huth ha scritto:
>
> > on travis-ci.com you can
> > only get free CI minutes for non-sponsored FOSS projects.
> > So let's simply not worry about Travis-CI anymore.
> >
> > Maybe we could rather
Il gio 7 gen 2021, 20:05 Thomas Huth ha scritto:
> on travis-ci.com you can
> only get free CI minutes for non-sponsored FOSS projects.
> So let's simply not worry about Travis-CI anymore.
>
> Maybe we could rather disable shippable now that we support the cross
> container builds on gitlab-ci,
On 07/01/2021 19.28, Daniel P. Berrangé wrote:
[...]
Travis has issues with git cloning and concurrent pushes.
eg if you push branch A, it schedules a CI job. Then you
push branch B before jobs for A have started.
When the job for A starts, it will be unable to checkout
the commit for branch
On Thu, Jan 07, 2021 at 06:17:19PM +0100, Paolo Bonzini wrote:
> We are still using quite a bit of bandwidth to run CI jobs, even though
> GitLab has switched to gitlab.com to fetch the sources. This is in
> part because we are handling submodules ourselves and therefore those
> do not use
We are still using quite a bit of bandwidth to run CI jobs, even though
GitLab has switched to gitlab.com to fetch the sources. This is in
part because we are handling submodules ourselves and therefore those
do not use shallow clones.
Observe GitLab's GIT_DEPTH environment variable in
