Build base archives for CI in a separate repository

[Zero King]

On Fri, Jul 28, 2017 at 02:20:47PM +0200, Rainer Müller wrote:
>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.

I may need to update the CI archives between MacPorts releases. That's
why I used an extra letter.

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

No, PRs won't have access to the secrets.

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

Of course I'll keep it in the MacPorts organization. The discussion
isn't over yet and right now I don't have a working implementation for
either approach.

-- 
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/20170728/ca0552bb/attachment.bin>