Re: Time to remove Travis support?

2020-11-27 Thread Zero King

On Fri, Nov 27, 2020 at 10:27:09PM +0100, Clemens Lang wrote:

Hi,

On Fri, Nov 27, 2020 at 04:24:01PM +, Zero King wrote:
[...]

Sure. Let's do it before end of the year. I'll see what I can do about
the build log comment, but GitHub Actions IPs have to be whitelisted
on paste.macports.org first.


From what I've seen, the GitHub Actions-based builds seems to have
enough storage so we can just avoid the pastebot completely?


I want to stay in the browser and have a direct link to view the logs I
need. Having to download and extract the zip file to find that log file
is not so convenient.

OTOH, we could implement a service that automatically pulls logs from
GitHub Actions and generated predictable URLs for viewing. In this way,
the service could go down for maintenance without missing any logs, and
the PR bot could reference these URLs before they are ready.


See for example [1], which produced 357 MB logs (27 MB zipped), and
doesn't seem to have a problem with it.


[1]: https://github.com/macports/macports-ports/actions/runs/386150389


Re: Time to remove Travis support?

2020-11-27 Thread Clemens Lang
Hi,

On Fri, Nov 27, 2020 at 04:24:01PM +, Zero King wrote:
> Beware that we have other repositories under our organization that are
> using travis-ci.org, and they have to migrate away as well. For
> example, https://github.com/macports/macports-webapp.

It's probably not complicated to migrate those, but I'd also not make it
a huge priority. Let's get rid of Travis first, then deal with
re-creating the CI on a new platform.

> Sure. Let's do it before end of the year. I'll see what I can do about
> the build log comment, but GitHub Actions IPs have to be whitelisted
> on paste.macports.org first.

>From what I've seen, the GitHub Actions-based builds seems to have
enough storage so we can just avoid the pastebot completely?

See for example [1], which produced 357 MB logs (27 MB zipped), and
doesn't seem to have a problem with it.


[1]: https://github.com/macports/macports-ports/actions/runs/386150389

-- 
Clemens


Re: Time to remove Travis support?

2020-11-27 Thread Ryan Schmidt



> On Nov 27, 2020, at 10:24, Zero King wrote:
> 
> If we can install .pkgs from the command line and
> skip the initial sync (in the postflight script), we could throw it away
> and just use official pkg installers.

Yes I would like that. I spent some time awhile back rewriting the installer 
with separate subpkgs so that you could skip some of them, like the one that 
runs selfupdate, but the work is not finished. 


Re: Time to remove Travis support?

2020-11-27 Thread Zero King

On Mon, Nov 02, 2020 at 08:14:17PM +0100, Mojca Miklavec wrote:

Hi,

If I understand correctly, we'll soon be unable to run any builds on
Travis unless we pay for it (they are gradually moving existing
customers to the new billing plan, so it's just a matter of time):
   https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing


The travis-ci.org platform we are using will be disabled on or after
Dec. 31st, 2020[1]. Given this new billing plan, I'd rather just remove
Travis CI from our repos.

Beware that we have other repositories under our organization that are
using travis-ci.org, and they have to migrate away as well. For example,
https://github.com/macports/macports-webapp.


We cannot say that this wasn't expected, so maybe it's time to put the
last nail in that coffin? I don't know if we can expand the OS version
list in any of the other services (GitHub Actions or Azure), but it's
ok even if we don't.


Sure. Let's do it before end of the year. I'll see what I can do about
the build log comment, but GitHub Actions IPs have to be whitelisted on
paste.macports.org first.

I'll keep Azure around for macOS-10.14, but I think Microsoft will
eventually unify build environments on Azure and GH Actions, and we will
keep just GH Actions for convenience.

Generation of CI tarballs from macports-base would have to be migrated
to other CI systems. If we can install .pkgs from the command line and
skip the initial sync (in the postflight script), we could throw it away
and just use official pkg installers.

[1]: 
https://docs.travis-ci.com/user/migrate/open-source-repository-migration#q-what-will-happen-to-travis-ciorg-after-december-31st-2020