Re: [NOTICE] Travis CI .org -> .com move, action required.

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: [NOTICE] Travis CI .org -> .com move, action required.

Robbie Gemmell
Administrator
On Mon, 23 Nov 2020 at 16:04, Robbie Gemmell <[hidden email]> wrote:

>
> Hi folks,
>
> Short version:
> 1) The Travis build jobs will migrate to a new URL, on their .com site
> rather than .org, links etc will need to be updated.
> 2) Travis have introduced relatively tiny default resource limits for
> free users, so you may want to disable Travis on your Github forks to
> save them until really needed (or you can apparently individually
> apply for a higher limit).
>
> Expanded version:
> First up, as some of you may know Travis CI is migrating away from use
> of https://travis-ci.org to solely using their other
> https://travis-ci.com site. This has been underway for many years at
> this point with no real traction, but a final deadline of Dec 31st has
> been set for the .org bits to become defunct, and worker nodes have
> been migrating across for weeks now, so the point has come a switch is
> required.
>
> When done, the existing URLs will just give a landing page saying the
> build moved, with a link to go to it. Folks using the existing URLs
> for build status etc will need to update their references.
>
> Infra started to migrate some jobs over themselves, and also migrate
> the paid ASF concurrency limits plan across for the apache github org.
> They decided they didnt want to end up migrating >2000 jobs when many
> aren't really used anymore, and so have asked for the remainder that
> migrations be requested.
>
> None of ours appear to have been moved yet, so I have requested [1]
> that infra do the migration for these repositories:
> qpid-broker-j
> qpid-dispatch
> qpid-jms
> qpid-proton
> qpid-proton-j
> qpid-site
>
> Secondly, note that Travis have significantly changed the terms for
> 'free' usage on travis-ci.com during this process, to 'combat abuse'.
> The effect is that it severely curtails usage for non paying folks, or
> folks who dont fill out a form to get an
> individually-requested/tailored 'allotment of OSS minutes':
> https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
>
> I know the ASF have paid for additional resources at Travis for a long
> time, so I dont think this really impacts things for the main
> repositories, but I think this probably presents an issue for
> developers forks. As such, folks might want to disable the Travis
> integration on their forks to stop it burning the very limited .com
> resource you will have available by default. Folks working on
> components that dont have Github Actions / Appveyor / Jenkins / Other
> builds in addition to Travis, might also wish to establish some as an
> alternative for PRs etc.
>
> Robbie
>
> [1] https://lists.apache.org/thread.html/r2863a94f8a37986594f44bd36b16d4065e9d09c25c90fc3b5f052e41%40%3Cbuilds.apache.org%3E

On the resource limits bit regarding forks, I haven't migrated a repo
build from the .org to .com site before, so in retrospect I dont
actually know if the build would automatically become enabled on the
.com site for your forks or if you need to enable it separately again.
That is, it may be a case of not-enabling it again, rather than
disabling it, in order to preserve the limited usage allowance should
you need it later (and/or not want to ask, or not be successful in
asking, for a sufficient amount of credits to leave it enabled all the
time on your forks).

Reading their details again, it also seems like perhaps OSX usage will
require a paid addon plan/credits, in which case those bits of the
builds will probably just need to be disabled (and/or moved to GitHub
Actions etc)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]