You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2020/11/23 16:04:43 UTC
[NOTICE] Travis CI .org -> .com move, action required.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Jiri Daněk <jd...@redhat.com>.
On Wed, Dec 2, 2020 at 1:12 PM Robbie Gemmell <ro...@gmail.com>
wrote:
> > > > > Qpid Dispatch has a mac build and it looks like we might have to
> pay for
> > > > it
> > > > > if we want to keep it around by purchasing what they
> > > > > call credits (1 minute of mac build time costs 50 credits). Do we
> want to
> > > > > do this? Or are we just going to drop the mac os builds?
> > > > >
> > > >
> > > > We would surely drop it from the Travis build in that case.
> > > >
> > > > GitHub Actions also has MacOS build nodes, so that build workflow
> > > > could be updated to use them if desired.
> > > >
> > >
> > > Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
> > >
> > > We'll probably want to make the same change in Proton as well.
> >
> > For the removal from Travis, yep. The GHA build for Proton already
> > runs on OSX currently as you no doubt know.
>
>
> I ended up raising a JIRA for this,
> https://issues.apache.org/jira/browse/INFRA-21154, which has now been
> actioned. All the repository jobs have now been migrated to the .com
> site.
>
> I have prodded the various jobs to run, updating some READMEs and the
> website to use links/badges from the .com site. Once they run, the
> .org site updates to say only that the jobs were migrated and give a
> link to the .com site.
>
> The OSX elements of the Proton and Dispatch builds did execute,
> whereas I expected the job to error immediately. This could be as the
> ASF's plan has some life left (seems pricing migration happens at
> plan-end), or they've got some OSX credits, unclear. I have asked
> about those on the Infra JIRA to see what expectations are going
> forward.
>
> From a quick test I did the migration within the apache github org
> seems to have no effect on our forks, which makes sense. This means
> your forks with .org enabled builds will continue to try building
> there, with its dwindling resources, until it goes defunct on Dec
> 31st. If you dont migrate or enable your fork build on the .com site
> it simply won't build after that presumably.
>
I've spent some time on migrating the Dispatch macOS Travis job to GitHub
Actions and I got stuck on a freeze that I was unable to debug. I found
some working GitHub Actions that are using MacPorts, so as a next step I
would be trying to steal working bits from those. Alternatively, I could
drop MacPorts and use Brew, and either build Cyrus SASL myself, or just
live without it {SASL itself is part of macOS, but it is deprecated, and
the utility programs to manage the DB are missing).
Link to the stuck Action,
https://github.com/jiridanek/qpid-dispatch/runs/1473498467?check_suite_focus=true
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Wed, 2 Dec 2020 at 12:02, Robbie Gemmell <ro...@gmail.com> wrote:
>
> On Tue, 24 Nov 2020 at 17:00, Robbie Gemmell <ro...@gmail.com> wrote:
> >
> > On Tue, 24 Nov 2020 at 16:30, Jiri Daněk <jd...@redhat.com> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell <ro...@gmail.com>
> > > wrote:
> > >
> > > > On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
> > > > >
> > > > > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> > > > robbie.gemmell@gmail.com>
> > > > > 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
> > > > >
> > > > > Thanks for doing this! So it looks like no other additional action is
> > > > > required on our side.
> > > > > Once this migration is complete, we will be as usual able to access the
> > > > > Travis
> > > > > builds from the github <https://github.com/apache/qpid-dispatch> website
> > > > > with the just the one difference that the Travis build URLs
> > > > > will point to the .com website.
> > > > >
> > > >
> > > > Should be the case yep.
> > > >
> > > > > With regards to the resource limits on forks, it looks like we will have
> > > > to
> > > > > wait to see if they automatically
> > > > > enable builds or if they will make us enable it. If they don't enable
> > > > it,
> > > > > I don't plan on enabling it.
> > > > > Again, no action required from our side if they don't enable it.
> > > > >
> > > >
> > > > Yep.
> > > >
> > > > > Qpid Dispatch has a mac build and it looks like we might have to pay for
> > > > it
> > > > > if we want to keep it around by purchasing what they
> > > > > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > > > > do this? Or are we just going to drop the mac os builds?
> > > > >
> > > >
> > > > We would surely drop it from the Travis build in that case.
> > > >
> > > > GitHub Actions also has MacOS build nodes, so that build workflow
> > > > could be updated to use them if desired.
> > > >
> > >
> > > Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
> > >
> > > We'll probably want to make the same change in Proton as well.
> >
> > For the removal from Travis, yep. The GHA build for Proton already
> > runs on OSX currently as you no doubt know.
>
>
> I ended up raising a JIRA for this,
> https://issues.apache.org/jira/browse/INFRA-21154, which has now been
> actioned. All the repository jobs have now been migrated to the .com
> site.
>
> I have prodded the various jobs to run, updating some READMEs and the
> website to use links/badges from the .com site. Once they run, the
> .org site updates to say only that the jobs were migrated and give a
> link to the .com site.
>
> The OSX elements of the Proton and Dispatch builds did execute,
> whereas I expected the job to error immediately. This could be as the
> ASF's plan has some life left (seems pricing migration happens at
> plan-end), or they've got some OSX credits, unclear. I have asked
> about those on the Infra JIRA to see what expectations are going
> forward.
I only got a short 'we pay for extra resources' reply, so I'm still
not too sure overall.
>
> From a quick test I did the migration within the apache github org
> seems to have no effect on our forks, which makes sense. This means
> your forks with .org enabled builds will continue to try building
> there, with its dwindling resources, until it goes defunct on Dec
> 31st. If you dont migrate or enable your fork build on the .com site
> it simply won't build after that presumably.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Wed, 2 Dec 2020 at 12:02, Robbie Gemmell <ro...@gmail.com> wrote:
>
> On Tue, 24 Nov 2020 at 17:00, Robbie Gemmell <ro...@gmail.com> wrote:
> >
> > On Tue, 24 Nov 2020 at 16:30, Jiri Daněk <jd...@redhat.com> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell <ro...@gmail.com>
> > > wrote:
> > >
> > > > On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
> > > > >
> > > > > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> > > > robbie.gemmell@gmail.com>
> > > > > 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
> > > > >
> > > > > Thanks for doing this! So it looks like no other additional action is
> > > > > required on our side.
> > > > > Once this migration is complete, we will be as usual able to access the
> > > > > Travis
> > > > > builds from the github <https://github.com/apache/qpid-dispatch> website
> > > > > with the just the one difference that the Travis build URLs
> > > > > will point to the .com website.
> > > > >
> > > >
> > > > Should be the case yep.
> > > >
> > > > > With regards to the resource limits on forks, it looks like we will have
> > > > to
> > > > > wait to see if they automatically
> > > > > enable builds or if they will make us enable it. If they don't enable
> > > > it,
> > > > > I don't plan on enabling it.
> > > > > Again, no action required from our side if they don't enable it.
> > > > >
> > > >
> > > > Yep.
> > > >
> > > > > Qpid Dispatch has a mac build and it looks like we might have to pay for
> > > > it
> > > > > if we want to keep it around by purchasing what they
> > > > > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > > > > do this? Or are we just going to drop the mac os builds?
> > > > >
> > > >
> > > > We would surely drop it from the Travis build in that case.
> > > >
> > > > GitHub Actions also has MacOS build nodes, so that build workflow
> > > > could be updated to use them if desired.
> > > >
> > >
> > > Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
> > >
> > > We'll probably want to make the same change in Proton as well.
> >
> > For the removal from Travis, yep. The GHA build for Proton already
> > runs on OSX currently as you no doubt know.
>
>
> I ended up raising a JIRA for this,
> https://issues.apache.org/jira/browse/INFRA-21154, which has now been
> actioned. All the repository jobs have now been migrated to the .com
> site.
>
> I have prodded the various jobs to run, updating some READMEs and the
> website to use links/badges from the .com site. Once they run, the
> .org site updates to say only that the jobs were migrated and give a
> link to the .com site.
>
> The OSX elements of the Proton and Dispatch builds did execute,
> whereas I expected the job to error immediately. This could be as the
> ASF's plan has some life left (seems pricing migration happens at
> plan-end), or they've got some OSX credits, unclear. I have asked
> about those on the Infra JIRA to see what expectations are going
> forward.
I only got a short 'we pay for extra resources' reply, so I'm still
not too sure overall.
>
> From a quick test I did the migration within the apache github org
> seems to have no effect on our forks, which makes sense. This means
> your forks with .org enabled builds will continue to try building
> there, with its dwindling resources, until it goes defunct on Dec
> 31st. If you dont migrate or enable your fork build on the .com site
> it simply won't build after that presumably.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Jiri Daněk <jd...@redhat.com>.
On Wed, Dec 2, 2020 at 1:12 PM Robbie Gemmell <ro...@gmail.com>
wrote:
> > > > > Qpid Dispatch has a mac build and it looks like we might have to
> pay for
> > > > it
> > > > > if we want to keep it around by purchasing what they
> > > > > call credits (1 minute of mac build time costs 50 credits). Do we
> want to
> > > > > do this? Or are we just going to drop the mac os builds?
> > > > >
> > > >
> > > > We would surely drop it from the Travis build in that case.
> > > >
> > > > GitHub Actions also has MacOS build nodes, so that build workflow
> > > > could be updated to use them if desired.
> > > >
> > >
> > > Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
> > >
> > > We'll probably want to make the same change in Proton as well.
> >
> > For the removal from Travis, yep. The GHA build for Proton already
> > runs on OSX currently as you no doubt know.
>
>
> I ended up raising a JIRA for this,
> https://issues.apache.org/jira/browse/INFRA-21154, which has now been
> actioned. All the repository jobs have now been migrated to the .com
> site.
>
> I have prodded the various jobs to run, updating some READMEs and the
> website to use links/badges from the .com site. Once they run, the
> .org site updates to say only that the jobs were migrated and give a
> link to the .com site.
>
> The OSX elements of the Proton and Dispatch builds did execute,
> whereas I expected the job to error immediately. This could be as the
> ASF's plan has some life left (seems pricing migration happens at
> plan-end), or they've got some OSX credits, unclear. I have asked
> about those on the Infra JIRA to see what expectations are going
> forward.
>
> From a quick test I did the migration within the apache github org
> seems to have no effect on our forks, which makes sense. This means
> your forks with .org enabled builds will continue to try building
> there, with its dwindling resources, until it goes defunct on Dec
> 31st. If you dont migrate or enable your fork build on the .com site
> it simply won't build after that presumably.
>
I've spent some time on migrating the Dispatch macOS Travis job to GitHub
Actions and I got stuck on a freeze that I was unable to debug. I found
some working GitHub Actions that are using MacPorts, so as a next step I
would be trying to steal working bits from those. Alternatively, I could
drop MacPorts and use Brew, and either build Cyrus SASL myself, or just
live without it {SASL itself is part of macOS, but it is deprecated, and
the utility programs to manage the DB are missing).
Link to the stuck Action,
https://github.com/jiridanek/qpid-dispatch/runs/1473498467?check_suite_focus=true
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Tue, 24 Nov 2020 at 17:00, Robbie Gemmell <ro...@gmail.com> wrote:
>
> On Tue, 24 Nov 2020 at 16:30, Jiri Daněk <jd...@redhat.com> wrote:
> >
> > On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> > > On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
> > > >
> > > > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> > > robbie.gemmell@gmail.com>
> > > > 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
> > > >
> > > > Thanks for doing this! So it looks like no other additional action is
> > > > required on our side.
> > > > Once this migration is complete, we will be as usual able to access the
> > > > Travis
> > > > builds from the github <https://github.com/apache/qpid-dispatch> website
> > > > with the just the one difference that the Travis build URLs
> > > > will point to the .com website.
> > > >
> > >
> > > Should be the case yep.
> > >
> > > > With regards to the resource limits on forks, it looks like we will have
> > > to
> > > > wait to see if they automatically
> > > > enable builds or if they will make us enable it. If they don't enable
> > > it,
> > > > I don't plan on enabling it.
> > > > Again, no action required from our side if they don't enable it.
> > > >
> > >
> > > Yep.
> > >
> > > > Qpid Dispatch has a mac build and it looks like we might have to pay for
> > > it
> > > > if we want to keep it around by purchasing what they
> > > > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > > > do this? Or are we just going to drop the mac os builds?
> > > >
> > >
> > > We would surely drop it from the Travis build in that case.
> > >
> > > GitHub Actions also has MacOS build nodes, so that build workflow
> > > could be updated to use them if desired.
> > >
> >
> > Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
> >
> > We'll probably want to make the same change in Proton as well.
>
> For the removal from Travis, yep. The GHA build for Proton already
> runs on OSX currently as you no doubt know.
I ended up raising a JIRA for this,
https://issues.apache.org/jira/browse/INFRA-21154, which has now been
actioned. All the repository jobs have now been migrated to the .com
site.
I have prodded the various jobs to run, updating some READMEs and the
website to use links/badges from the .com site. Once they run, the
.org site updates to say only that the jobs were migrated and give a
link to the .com site.
The OSX elements of the Proton and Dispatch builds did execute,
whereas I expected the job to error immediately. This could be as the
ASF's plan has some life left (seems pricing migration happens at
plan-end), or they've got some OSX credits, unclear. I have asked
about those on the Infra JIRA to see what expectations are going
forward.
From a quick test I did the migration within the apache github org
seems to have no effect on our forks, which makes sense. This means
your forks with .org enabled builds will continue to try building
there, with its dwindling resources, until it goes defunct on Dec
31st. If you dont migrate or enable your fork build on the .com site
it simply won't build after that presumably.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Tue, 24 Nov 2020 at 17:00, Robbie Gemmell <ro...@gmail.com> wrote:
>
> On Tue, 24 Nov 2020 at 16:30, Jiri Daněk <jd...@redhat.com> wrote:
> >
> > On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> > > On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
> > > >
> > > > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> > > robbie.gemmell@gmail.com>
> > > > 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
> > > >
> > > > Thanks for doing this! So it looks like no other additional action is
> > > > required on our side.
> > > > Once this migration is complete, we will be as usual able to access the
> > > > Travis
> > > > builds from the github <https://github.com/apache/qpid-dispatch> website
> > > > with the just the one difference that the Travis build URLs
> > > > will point to the .com website.
> > > >
> > >
> > > Should be the case yep.
> > >
> > > > With regards to the resource limits on forks, it looks like we will have
> > > to
> > > > wait to see if they automatically
> > > > enable builds or if they will make us enable it. If they don't enable
> > > it,
> > > > I don't plan on enabling it.
> > > > Again, no action required from our side if they don't enable it.
> > > >
> > >
> > > Yep.
> > >
> > > > Qpid Dispatch has a mac build and it looks like we might have to pay for
> > > it
> > > > if we want to keep it around by purchasing what they
> > > > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > > > do this? Or are we just going to drop the mac os builds?
> > > >
> > >
> > > We would surely drop it from the Travis build in that case.
> > >
> > > GitHub Actions also has MacOS build nodes, so that build workflow
> > > could be updated to use them if desired.
> > >
> >
> > Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
> >
> > We'll probably want to make the same change in Proton as well.
>
> For the removal from Travis, yep. The GHA build for Proton already
> runs on OSX currently as you no doubt know.
I ended up raising a JIRA for this,
https://issues.apache.org/jira/browse/INFRA-21154, which has now been
actioned. All the repository jobs have now been migrated to the .com
site.
I have prodded the various jobs to run, updating some READMEs and the
website to use links/badges from the .com site. Once they run, the
.org site updates to say only that the jobs were migrated and give a
link to the .com site.
The OSX elements of the Proton and Dispatch builds did execute,
whereas I expected the job to error immediately. This could be as the
ASF's plan has some life left (seems pricing migration happens at
plan-end), or they've got some OSX credits, unclear. I have asked
about those on the Infra JIRA to see what expectations are going
forward.
From a quick test I did the migration within the apache github org
seems to have no effect on our forks, which makes sense. This means
your forks with .org enabled builds will continue to try building
there, with its dwindling resources, until it goes defunct on Dec
31st. If you dont migrate or enable your fork build on the .com site
it simply won't build after that presumably.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Tue, 24 Nov 2020 at 16:30, Jiri Daněk <jd...@redhat.com> wrote:
>
> On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
> > >
> > > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> > robbie.gemmell@gmail.com>
> > > 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
> > >
> > > Thanks for doing this! So it looks like no other additional action is
> > > required on our side.
> > > Once this migration is complete, we will be as usual able to access the
> > > Travis
> > > builds from the github <https://github.com/apache/qpid-dispatch> website
> > > with the just the one difference that the Travis build URLs
> > > will point to the .com website.
> > >
> >
> > Should be the case yep.
> >
> > > With regards to the resource limits on forks, it looks like we will have
> > to
> > > wait to see if they automatically
> > > enable builds or if they will make us enable it. If they don't enable
> > it,
> > > I don't plan on enabling it.
> > > Again, no action required from our side if they don't enable it.
> > >
> >
> > Yep.
> >
> > > Qpid Dispatch has a mac build and it looks like we might have to pay for
> > it
> > > if we want to keep it around by purchasing what they
> > > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > > do this? Or are we just going to drop the mac os builds?
> > >
> >
> > We would surely drop it from the Travis build in that case.
> >
> > GitHub Actions also has MacOS build nodes, so that build workflow
> > could be updated to use them if desired.
> >
>
> Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
>
> We'll probably want to make the same change in Proton as well.
For the removal from Travis, yep. The GHA build for Proton already
runs on OSX currently as you no doubt know.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Tue, 24 Nov 2020 at 16:30, Jiri Daněk <jd...@redhat.com> wrote:
>
> On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
> > >
> > > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> > robbie.gemmell@gmail.com>
> > > 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
> > >
> > > Thanks for doing this! So it looks like no other additional action is
> > > required on our side.
> > > Once this migration is complete, we will be as usual able to access the
> > > Travis
> > > builds from the github <https://github.com/apache/qpid-dispatch> website
> > > with the just the one difference that the Travis build URLs
> > > will point to the .com website.
> > >
> >
> > Should be the case yep.
> >
> > > With regards to the resource limits on forks, it looks like we will have
> > to
> > > wait to see if they automatically
> > > enable builds or if they will make us enable it. If they don't enable
> > it,
> > > I don't plan on enabling it.
> > > Again, no action required from our side if they don't enable it.
> > >
> >
> > Yep.
> >
> > > Qpid Dispatch has a mac build and it looks like we might have to pay for
> > it
> > > if we want to keep it around by purchasing what they
> > > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > > do this? Or are we just going to drop the mac os builds?
> > >
> >
> > We would surely drop it from the Travis build in that case.
> >
> > GitHub Actions also has MacOS build nodes, so that build workflow
> > could be updated to use them if desired.
> >
>
> Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
>
> We'll probably want to make the same change in Proton as well.
For the removal from Travis, yep. The GHA build for Proton already
runs on OSX currently as you no doubt know.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Jiri Daněk <jd...@redhat.com>.
On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell <ro...@gmail.com>
wrote:
> On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
> >
> > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> robbie.gemmell@gmail.com>
> > 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
> >
> > Thanks for doing this! So it looks like no other additional action is
> > required on our side.
> > Once this migration is complete, we will be as usual able to access the
> > Travis
> > builds from the github <https://github.com/apache/qpid-dispatch> website
> > with the just the one difference that the Travis build URLs
> > will point to the .com website.
> >
>
> Should be the case yep.
>
> > With regards to the resource limits on forks, it looks like we will have
> to
> > wait to see if they automatically
> > enable builds or if they will make us enable it. If they don't enable
> it,
> > I don't plan on enabling it.
> > Again, no action required from our side if they don't enable it.
> >
>
> Yep.
>
> > Qpid Dispatch has a mac build and it looks like we might have to pay for
> it
> > if we want to keep it around by purchasing what they
> > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > do this? Or are we just going to drop the mac os builds?
> >
>
> We would surely drop it from the Travis build in that case.
>
> GitHub Actions also has MacOS build nodes, so that build workflow
> could be updated to use them if desired.
>
Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
We'll probably want to make the same change in Proton as well.
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Jiri Daněk <jd...@redhat.com>.
On Tue, Nov 24, 2020 at 4:52 PM Robbie Gemmell <ro...@gmail.com>
wrote:
> On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
> >
> > On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <
> robbie.gemmell@gmail.com>
> > 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
> >
> > Thanks for doing this! So it looks like no other additional action is
> > required on our side.
> > Once this migration is complete, we will be as usual able to access the
> > Travis
> > builds from the github <https://github.com/apache/qpid-dispatch> website
> > with the just the one difference that the Travis build URLs
> > will point to the .com website.
> >
>
> Should be the case yep.
>
> > With regards to the resource limits on forks, it looks like we will have
> to
> > wait to see if they automatically
> > enable builds or if they will make us enable it. If they don't enable
> it,
> > I don't plan on enabling it.
> > Again, no action required from our side if they don't enable it.
> >
>
> Yep.
>
> > Qpid Dispatch has a mac build and it looks like we might have to pay for
> it
> > if we want to keep it around by purchasing what they
> > call credits (1 minute of mac build time costs 50 credits). Do we want to
> > do this? Or are we just going to drop the mac os builds?
> >
>
> We would surely drop it from the Travis build in that case.
>
> GitHub Actions also has MacOS build nodes, so that build workflow
> could be updated to use them if desired.
>
Dispatch ticket https://issues.apache.org/jira/browse/DISPATCH-1855
We'll probably want to make the same change in Proton as well.
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
>
> On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <ro...@gmail.com>
> 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
>
> Thanks for doing this! So it looks like no other additional action is
> required on our side.
> Once this migration is complete, we will be as usual able to access the
> Travis
> builds from the github <https://github.com/apache/qpid-dispatch> website
> with the just the one difference that the Travis build URLs
> will point to the .com website.
>
Should be the case yep.
> With regards to the resource limits on forks, it looks like we will have to
> wait to see if they automatically
> enable builds or if they will make us enable it. If they don't enable it,
> I don't plan on enabling it.
> Again, no action required from our side if they don't enable it.
>
Yep.
> Qpid Dispatch has a mac build and it looks like we might have to pay for it
> if we want to keep it around by purchasing what they
> call credits (1 minute of mac build time costs 50 credits). Do we want to
> do this? Or are we just going to drop the mac os builds?
>
We would surely drop it from the Travis build in that case.
GitHub Actions also has MacOS build nodes, so that build workflow
could be updated to use them if desired.
> >
> > 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.
> >
> I did not realize that the ASF folks were paying Travis (for additional
> resources). I always thought
> that Travis was free for open source projects.
>
There are resource limits applied within a given github org, and since
the ASF projects are all under the apache org that makes for a lot of
contention for the free resources. Particularly with some projects
having monstrous builds (in terms of length and/or executor usage)
utterly drowning out smaller or less frequent builds. The basic limits
just wouldn't work for the org, you'd probably be waiting days or more
for builds to run, so ASF infra pays for increased concurrency such
that the backlog more manageable (and even then, its still fairly
typical jobs have to wait some during peak times, certainly longer
than they do on a personal fork building outside the org limits...this
may ease as certain larger projects decide to use other services
instead though, as the use-shiny-new-CI-service loop repeats once
again, with extra prodding from these changes).
> >
> > Robbie
> >
> > [1]
> > https://lists.apache.org/thread.html/r2863a94f8a37986594f44bd36b16d4065e9d09c25c90fc3b5f052e41%40%3Cbuilds.apache.org%3E
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Tue, 24 Nov 2020 at 14:44, Ganesh Murthy <gm...@redhat.com> wrote:
>
> On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <ro...@gmail.com>
> 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
>
> Thanks for doing this! So it looks like no other additional action is
> required on our side.
> Once this migration is complete, we will be as usual able to access the
> Travis
> builds from the github <https://github.com/apache/qpid-dispatch> website
> with the just the one difference that the Travis build URLs
> will point to the .com website.
>
Should be the case yep.
> With regards to the resource limits on forks, it looks like we will have to
> wait to see if they automatically
> enable builds or if they will make us enable it. If they don't enable it,
> I don't plan on enabling it.
> Again, no action required from our side if they don't enable it.
>
Yep.
> Qpid Dispatch has a mac build and it looks like we might have to pay for it
> if we want to keep it around by purchasing what they
> call credits (1 minute of mac build time costs 50 credits). Do we want to
> do this? Or are we just going to drop the mac os builds?
>
We would surely drop it from the Travis build in that case.
GitHub Actions also has MacOS build nodes, so that build workflow
could be updated to use them if desired.
> >
> > 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.
> >
> I did not realize that the ASF folks were paying Travis (for additional
> resources). I always thought
> that Travis was free for open source projects.
>
There are resource limits applied within a given github org, and since
the ASF projects are all under the apache org that makes for a lot of
contention for the free resources. Particularly with some projects
having monstrous builds (in terms of length and/or executor usage)
utterly drowning out smaller or less frequent builds. The basic limits
just wouldn't work for the org, you'd probably be waiting days or more
for builds to run, so ASF infra pays for increased concurrency such
that the backlog more manageable (and even then, its still fairly
typical jobs have to wait some during peak times, certainly longer
than they do on a personal fork building outside the org limits...this
may ease as certain larger projects decide to use other services
instead though, as the use-shiny-new-CI-service loop repeats once
again, with extra prodding from these changes).
> >
> > Robbie
> >
> > [1]
> > https://lists.apache.org/thread.html/r2863a94f8a37986594f44bd36b16d4065e9d09c25c90fc3b5f052e41%40%3Cbuilds.apache.org%3E
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Ganesh Murthy <gm...@redhat.com>.
On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <ro...@gmail.com>
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
Thanks for doing this! So it looks like no other additional action is
required on our side.
Once this migration is complete, we will be as usual able to access the
Travis
builds from the github <https://github.com/apache/qpid-dispatch> website
with the just the one difference that the Travis build URLs
will point to the .com website.
With regards to the resource limits on forks, it looks like we will have to
wait to see if they automatically
enable builds or if they will make us enable it. If they don't enable it,
I don't plan on enabling it.
Again, no action required from our side if they don't enable it.
Qpid Dispatch has a mac build and it looks like we might have to pay for it
if we want to keep it around by purchasing what they
call credits (1 minute of mac build time costs 50 credits). Do we want to
do this? Or are we just going to drop the mac os builds?
>
> 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.
>
I did not realize that the ASF folks were paying Travis (for additional
resources). I always thought
that Travis was free for open source projects.
>
> Robbie
>
> [1]
> https://lists.apache.org/thread.html/r2863a94f8a37986594f44bd36b16d4065e9d09c25c90fc3b5f052e41%40%3Cbuilds.apache.org%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Robbie Gemmell <ro...@gmail.com>.
On Mon, 23 Nov 2020 at 16:04, Robbie Gemmell <ro...@gmail.com> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [NOTICE] Travis CI .org -> .com move, action required.
Posted by Ganesh Murthy <gm...@redhat.com>.
On Mon, Nov 23, 2020 at 11:12 AM Robbie Gemmell <ro...@gmail.com>
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
Thanks for doing this! So it looks like no other additional action is
required on our side.
Once this migration is complete, we will be as usual able to access the
Travis
builds from the github <https://github.com/apache/qpid-dispatch> website
with the just the one difference that the Travis build URLs
will point to the .com website.
With regards to the resource limits on forks, it looks like we will have to
wait to see if they automatically
enable builds or if they will make us enable it. If they don't enable it,
I don't plan on enabling it.
Again, no action required from our side if they don't enable it.
Qpid Dispatch has a mac build and it looks like we might have to pay for it
if we want to keep it around by purchasing what they
call credits (1 minute of mac build time costs 50 credits). Do we want to
do this? Or are we just going to drop the mac os builds?
>
> 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.
>
I did not realize that the ASF folks were paying Travis (for additional
resources). I always thought
that Travis was free for open source projects.
>
> Robbie
>
> [1]
> https://lists.apache.org/thread.html/r2863a94f8a37986594f44bd36b16d4065e9d09c25c90fc3b5f052e41%40%3Cbuilds.apache.org%3E
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>