Build base archives for CI in a separate repository

[Zero King]

On Wed, Jul 26, 2017 at 06:19:16PM +0200, Clemens Lang wrote:
>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.

I prefer using a separate repository (only containing .travis.yml and
maybe patches, not MacPorts source) because I can update the binaries by
creating a new release (tag) on the same commit (MacPorts version can be
read from tag name) and keep the setup for ports CI away from
macports-base (they aren't related in my opinion).

>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.

From https://bintray.com/docs/terms_of_service.html:
You may not, whether by yourself or anyone on your behalf, unless otherwise explicitly permitted under these Terms:
(xxvii) in connection with Contributions, upload and/or store on the Site continuous integration artifacts or nightly builds, (i.e. you may only upload and store content in direct connection to official software releases).

A tag counts as official software releases. But the latest commit
doesn't.

>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.

That change didn't work and I committed another fix (not verified yet):
https://github.com/macports-staging/macports-base/commit/84b040fbcb1134e5cab1cc10cfc991c2d05c4824#diff-d7db55f70d83fc9dba4ef14de9febe71

Also, the other bug (Warning: Failed to copy com.apple.dt.Xcode.plist
... [1]) is not fixed.

[1] https://travis-ci.org/macports/macports-ports/jobs/249233655

>> 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

-- 
Best regards,
Zero King
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3612 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170727/53267446/attachment.bin>