Travis-CI changes

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

Recently Travis-CI have changed their limits for public repositories[1].
We've used up new free monthly limit in just 3 days. They do offer extra
limits for some open source projects, but the project requesting it must
meet the following criteria:

- - Project must be at least 3 months old and is in active development (with regular commits and activity)
- - Project meets the OSD specification
- - Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)
- - Project can not provide commercial services or distribute paid versions of the software

We do not meet the third one. I see following options:

1. Buy their paid plan - for $79/month we can have one parallel job (we
had 4) and unlimited time.
2. Migrate to alternative CI service. Specifically I have gitlab-ci in
mind.

The first option is not so cheap, but also we use CI quite a lot given
how fast we've used up the limit.

As for the second opiton, why gitlab-ci? Because Frédéric done most of
the integration already[2]. But there are still few options:
- use gitlab.com and connect our own worker(s)
- use Frédéric's gitlab instance
- setup separate gitlab instance

My main concern regarding which instance to use is about availability
and maintenance. I'd like to avoid situation when only one person can
fix things if something is broken. Believe it or not, some of us do
take vacations form time to time ;)

Any opinions? Any other options?

Please note, we're talking about just CI, not hosting our source code
(although setting up Gitlab CI will require source code mirroring too).
Migrating primary source code hosting, issues tracking etc would require
some more changes that I don't want to do in rush.

[1] https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
[2] https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl+tk4gACgkQ24/THMrX
1yyl9ggAgF+hghVlbUpbeaOujDFyLaxgNte7tk/hchRWdG5GENg8LYima2m73d1Y
8RsCFZVA1XzQL0K7E7SAIZAIulKzbws7GPQ4b2xxR4aFa6sQGRnTPEsy8CZ6gnlC
o3Ds3wM8H0zwnBUj8vogCdULqB6fEVAFSnY5bIYXOrd7IKKRcWFFXooozKy21jDi
otvkMgIKuxLdFvj+CET4vaq4d6ga80qUfg2nbFKLL8pml42RotIe42Fu9xYS+jnq
j3cCPuoaXhvP7J0t7VrlyyEzz9u2xAzsbwoRPfdHdFhPcUChIO7iiRiTNsaObT4b
DZnZOtaBf+cwVJMQ4u2t9S7DxeI1hw==
=Giax
-----END PGP SIGNATURE-----

[Demi M. Obenour]

GitLab CI seems to be a good choice. The GHC team has had good
experiences with it, for example. Since we consider the CI to be
untrusted, and since we want to minimize maintenance, I suggest using
https://gitlab.com as opposed to hosting our own instance.

Sincerely,

Demi

[Andrew David Wong]

On 11/12/20 1:39 PM, Demi M. Obenour wrote:
> On 11/12/20 2:56 PM, Marek Marczykowski-Górecki wrote:
>> Hi all,
>>
>> Recently Travis-CI have changed their limits for public repositories[1].
>> We've used up new free monthly limit in just 3 days. They do offer extra
>> limits for some open source projects, but the project requesting it must
>> meet the following criteria:
>>
>> - - Project must be at least 3 months old and is in active development (with regular commits and activity)
>> - - Project meets the OSD specification
>> - - Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)
>> - - Project can not provide commercial services or distribute paid versions of the software
>>
>> We do not meet the third one.

I can't help but wonder whether this is one of those situations in which
the rules have the opposite effect of the one intended. No doubt, their
intention is to make the service free for all and only open-source
projects that do valuable work but don't receive enough income to be
able to afford the service, which is exactly the situation in which the
Qubes OS Project finds itself, despite not meeting the third requirement.

>> I see following options:
>>
>> 1. Buy their paid plan - for $79/month we can have one parallel job (we
>> had 4) and unlimited time.
>> 2. Migrate to alternative CI service. Specifically I have gitlab-ci in
>> mind.
>>
>> The first option is not so cheap, but also we use CI quite a lot given
>> how fast we've used up the limit.
>>

I have no reason to doubt that Travis CI's paid plan is competitively
priced, but given the Qubes OS Project's modest funding, the opportunity
cost is too high.

>> As for the second opiton, why gitlab-ci? Because Frédéric done most of
>> the integration already[2]. But there are still few options:
>> - use gitlab.com and connect our own worker(s)
>> - use Frédéric's gitlab instance
>> - setup separate gitlab instance
>>
>> My main concern regarding which instance to use is about availability
>> and maintenance. I'd like to avoid situation when only one person can
>> fix things if something is broken. Believe it or not, some of us do
>> take vacations form time to time ;)
>>
>> Any opinions? Any other options?
>
> GitLab CI seems to be a good choice. The GHC team has had good
> experiences with it, for example. Since we consider the CI to be
> untrusted, and since we want to minimize maintenance, I suggest using
> https://gitlab.com as opposed to hosting our own instance.
>
> Sincerely,
>
> Demi
>

I agree with the GitLab CI option and using it in a way that minimizes
the maintenance overhead to the greatest extent possible.

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

[Wojtek Porczyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Nov 12, 2020 at 11:25:16PM -0800, Andrew David Wong wrote:
> On 11/12/20 1:39 PM, Demi M. Obenour wrote:
> > On 11/12/20 2:56 PM, Marek Marczykowski-Górecki wrote:
> > > Hi all,
> > >
> > > Recently Travis-CI have changed their limits for public repositories[1].
> > > We've used up new free monthly limit in just 3 days. They do offer extra
> > > limits for some open source projects, but the project requesting it must
> > > meet the following criteria:
> > >
> > > - - Project must be at least 3 months old and is in active development (with regular commits and activity)
> > > - - Project meets the OSD specification
> > > - - Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)
> > > - - Project can not provide commercial services or distribute paid versions of the software
> > >
> > > We do not meet the third one.
>
> I can't help but wonder whether this is one of those situations in which the
> rules have the opposite effect of the one intended. No doubt, their
> intention is to make the service free for all and only open-source projects
> that do valuable work but don't receive enough income to be able to afford
> the service, which is exactly the situation in which the Qubes OS Project
> finds itself, despite not meeting the third requirement.

I think their intention is to reduce costs, and supporting FOSS is secondary
to that. They left a nominal possibility for FOSS projects mainly to avoid
back PR while implementing this change. The amount of hoops the projects have
to jump through is significant enough that many projects will abandon travis
altogether.

[snip]

> > > As for the second opiton, why gitlab-ci? Because Frédéric done most of
> > > the integration already[2]. But there are still few options:
> > > - use gitlab.com and connect our own worker(s)
> > > - use Frédéric's gitlab instance
> > > - setup separate gitlab instance
> > >
> > > My main concern regarding which instance to use is about availability
> > > and maintenance. I'd like to avoid situation when only one person can
> > > fix things if something is broken. Believe it or not, some of us do
> > > take vacations form time to time ;)
> > >
> > > Any opinions? Any other options?
> >
> > GitLab CI seems to be a good choice. The GHC team has had good
> > experiences with it, for example. Since we consider the CI to be
> > untrusted, and since we want to minimize maintenance, I suggest using
> > https://gitlab.com as opposed to hosting our own instance.
> >
> > Sincerely,
> >
> > Demi
> >
>
> I agree with the GitLab CI option and using it in a way that minimizes the
> maintenance overhead to the greatest extent possible.

Wouldn't we have to maintain our own runners anyway?


- --
pozdrawiam / best regards
Wojtek Porczyk
Graphene / Invisible Things Lab

I do not fear computers,
I fear lack of them.
-- Isaac Asimov
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEaO0VFfpr0tEF6hYkv2vZMhA6I1EFAl+ub5wACgkQv2vZMhA6
I1GvoBAAgpwQ74LDRPeBvTAu9IZE2ACMwiuUB9g6t0DVlVx0yN+VBPrejqY2+9Xy
xKs1Efo7qWnzdSymVtgjPWwBwZsS0UP1sAPEjhBmogFa60o+vgXMWkIMaz5HKcQh
njwTXoCA9NqA6BE5lsUqGi+/qC4Z/3M5J0+Joc/5scv3IFfznmLWXW0OEUdHE0KK
8U/5p4kKWBmcMB9pKBpyFpRyb8MGRyadRj1TdRhTnao7PsqoonB9RoCYiwgaKdDz
y1+Jl1mcedwxddwn2HWImUjKMWqQuRIMbaVQmut98fY5wJgHt7kAUVI3QJJUm9J7
TbAj4eeALJJAZLYtdi4Wuxj+J5mIJWysfTdlT3j61YBr9Oic7ANFy3tKyj+vqdwn
x8dThmqBOSF7IlmVHCzuncjsUKro6ENe7Oc2DmciCSHMpyRKyMSBiGoYeujphPL5
SOk4n7k9EkPIZL18FR6h6uUdOpfse10gvLNbHwT5cgKdEjDONt5z6VODgYQMWCB8
PPPUokhysIVdn2+Q2FrMvMSExfivwxl/3wu3ThevuoKnzSMx6O4IQypSz3a5Ff+s
vn3UBSpgj/QWjxCqXPFSozZHfsUBDLeja3o0qmZSpvGOrMVG51upvJ0whjVg38xD
Opn4YDBn7+xQWtkhlejRlGfQkUJw2bgu1tV8nvWm3YhBEkZABms=
=pej5
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Nov 13, 2020 at 12:35:55PM +0100, Wojtek Porczyk wrote:
> On Thu, Nov 12, 2020 at 11:25:16PM -0800, Andrew David Wong wrote:
> > On 11/12/20 1:39 PM, Demi M. Obenour wrote:
> > > On 11/12/20 2:56 PM, Marek Marczykowski-Górecki wrote:
> > > > As for the second opiton, why gitlab-ci? Because Frédéric done most of
> > > > the integration already[2]. But there are still few options:
> > > > - use gitlab.com and connect our own worker(s)
> > > > - use Frédéric's gitlab instance
> > > > - setup separate gitlab instance
> > > >
> > > > My main concern regarding which instance to use is about availability
> > > > and maintenance. I'd like to avoid situation when only one person can
> > > > fix things if something is broken. Believe it or not, some of us do
> > > > take vacations form time to time ;)
> > > >
> > > > Any opinions? Any other options?
> > >
> > > GitLab CI seems to be a good choice. The GHC team has had good
> > > experiences with it, for example. Since we consider the CI to be
> > > untrusted, and since we want to minimize maintenance, I suggest using
> > > https://gitlab.com as opposed to hosting our own instance.
> > >
> > > Sincerely,
> > >
> > > Demi
> > >
> >
> > I agree with the GitLab CI option and using it in a way that minimizes the
> > maintenance overhead to the greatest extent possible.
>
> Wouldn't we have to maintain our own runners anyway?

I'm applying for Gitlab Gold license (free for open source projects),
which includes 50k CI minutes per month.
But as a fallback, yes, we'd need our runner(s). Fortunately, gitlab
made this trivial.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl+uckMACgkQ24/THMrX
1yxLVQf8DTpRaYkJW8WLufe8DcyHSuQgUwbwWF0mSBdLS1aAYG3rqkvPqnkEXiro
9np9kdTsktnxRSUy9lTsvE/K6Lwz3UswYsn5eUWLgBWvUARxUjTRHFYW5s6ulYbg
CNIZGXuIXzCthAbSPHsg+yjS8azjFa9KsG2WX9OrUfMVWQKpktiGboUbBUfkLKIT
fiNx+DLgst42K1QpusQ7PVjmeJUreL5F24eotyG3I9TtC1CZ9XeqVtuXbjiiA4rq
S0LDQE9Y3BMQioRiw+1qeW05Nd9j8277FVVtoo6tIJon9SS13BpaPLL0W4C6ATbH
R/E4vWWcjs18TyksLfvy0ZaYSvHCog==
=kUnn
-----END PGP SIGNATURE-----

[Frédéric Pierret]

Le 11/13/20 à 12:47 PM, Marek Marczykowski-Górecki a écrit :

Yes preparing a runner is just few minutes and maintaining it is "just" hardware cost maintenance.

Frédéric