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
smime.p7s
Description: S/MIME cryptographic signature
