Build base archives for CI in a separate repository

[Clemens Lang]

Hi,

----- On 28 Jul, 2017, at 04:06, Zero King l2dy at macports.org wrote:

> On Thu, Jul 27, 2017 at 07:56:27PM +0200, Clemens Lang wrote:
> > 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).

But we would get the same behavior by merging the 2.4.2 tag (or the
release-2.4 branch) into the ci branch, wouldn't we?


> 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'd say we should merge into the CI branch. I also agree that API keys
and the specific .travis.yml should never be merged from the CI branch
back to master (i.e. merging is only ever allowed in one direction). Since
close to no development that's also relevant for master should happen in
this branch, I think that's fine.


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

Those are an side effect of the move because we didn't have a different
place to put them. Ideally, we want users to claim them and remove them
from our org.


-- 
Clemens Lang