Build base archives for CI in a separate repository

[Clemens Lang]

Hi,

----- On 25 Jul, 2017, at 17:27, Rainer Müller raimue at macports.org wrote:

> On 2017-07-22 13:26, Zero King wrote:
>> In [1], I patched MacPorts in an attempt to fix a bug (port(1) failed
>> randomly on Travis). As it seems to be a Travis-specific bug, I plan to
>> use a separate repository to generate MacPorts archives used in CI and
>> keep the patch there. This way we can update the CI-specific archives
>> without a new release in macports-base (e.g. when new releases of macOS
>> become available on Travis).
>> 
>> [1]:
>> https://github.com/macports-staging/macports-base/commit/282e498ac51ba40bdfd43008ce430ca20a7d54ce#diff-d7db55f70d83fc9dba4ef14de9febe71
> 
> Should we keep a separate branch in the base repository for this? We
> could cherry-pick such hotfixes to that branch (could also be restricted
> to infrastructure team). I don't think we need a whole other repository
> for this and we should keep everything in one organization.

Exactly my thoughts as well. Having a separate branch allows us to quickly
deploy fixes without the overhead of a separate repository not used for
anything else.

Ideally, we should set up the macports-base Travis CI to automatically build
and publish the latest commit on that branch and the macports-ports CI to
automatically use the latest archive from that branch.

For example, we could upload a generated archive to Bintray and update a
file that always contains the URL to the latest archive and just download
that in the Travis CI job.


> Besides that, I see no reason that this change could not go into regular
> base with a comment explaining why it is necessary.

Agree here, please commit the change in macports-base.


> To debug the issue at hand, you could try to inject a
>  system "/bin/ls -laeO@ ${target_dir}"
> right before the 'file delete' to find out if there is anything like an
> immutable flag on this file or directory.

This might also happen if our builds are run under a sandbox, which could
denies deleting files in this location.

-- 
Clemens Lang