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