Build base archives for CI in a separate repository

[Zero King]

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

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

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.

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

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

https://travis-ci.org/macports-staging/macports-ports/jobs/257682551#L102

Tried once by adding it to .travis.yml, nothing abnormal. I'll try
adding that to source later. It's harder to redeploy the archives than
changing .travis.yml, but not as accurate for debugging.

>-- 
>Clemens

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