Build base archives for CI in a separate repository

[Clemens Lang]

Hi,

On Thu, Jul 27, 2017 at 01:51:31AM +0000, Zero King wrote:
> 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).

I would argue that the repository should in fact contain the MacPorts
source code. Ideally, without change in the repository, the build
results should be exactly the same, so there should be no need to
rebuild without a change in the repository. Remember that a change in
.travis.yml is also a code change worth a commit.

I also think that macports-base is very much related to the CI for
macports-ports just in the same way that macports-base in general is
related to macports-ports.

What's your use case for re-tagging on the same commit? I.e. what change
do you expect from rebuilding without changing something in the
repository (i.e. the .travis.yml file or the source).

Additionally, having a separate repository is very visible to users,
which do not care about the internals of our CI system implementation.


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

If we deploy the latest commit to production, that's a release, whether
it has a tag or not. In practice, I expect us to update this repository
once per MacPorts Base release and maybe once or twice in between, so
their main concern of huge disk space usage is probably not an issue.

Alternatively, we can also use a different service from the list
supported by Travis: https://docs.travis-ci.com/user/deployment/.


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

That would match my guess of sandboxing (or similar) being in place.

> 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

It's a warning only, so we might be able to just ignore it.

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

Have you tried this?

-- 
Clemens