Build base archives for CI in a separate repository

[Rainer Müller]

On 2017-07-28 04:06, Zero King wrote:
> On Thu, Jul 27, 2017 at 07:56:27PM +0200, Clemens Lang wrote:
>> 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).
> 
> The tag name changed. Currently, I'm using MacPorts version + a letter
> for tags (e.g. v2.4.1a). So when v2.4.2 is released, I can simply tag
> v2.4.2a and the build script can read the MacPorts version from the tag
> and fetch the source from distfiles.macports.org. This doesn't cover new
> macOS versions though (require changing .travis.yml).

v2.4.1a seems confusing to me, as it looks like a re-release.

My suggestion would be a travis-2.4 branch (to match release-2.4) with
tags named like travis-v2.4.1 in the macports-base repository. That
should sufficiently distinguish that this branch/tag is meant for CI only.

> Were we to use a branch, should we rebase onto or merge the release
> branch? I don't want to distribute API keys (though encrypted) in
> MacPorts releases, so I prefer that the CI branch not be merged into
> master or release branches.

I guess we cannot add the secrets to the Travis execution environment,
as there can only be one configuration per repository and that would
expose the secrets on pull requests?

If keeping secrets is a big problem, using a separate repository might
indeed be a solution, but I would keep it in the MacPorts organization.

Although we could also use the buildbot to recreate and deploy the base
archive, the track record for deploying stuff on build.macports.org
suggests that it would take at least months...

>> Additionally, having a separate repository is very visible to users,
>> which do not care about the internals of our CI system implementation.
> 
> We already have many macports-user-* repositories that are very visible
> but inactive.

Which is just old leftovers from Subversion. We wanted keep around for
some time before we remove them.

Rainer