gitlab-runner: new submission

[breun]

Description

New port for GitLab Runner.

Tested on

macOS 10.14.1 18B75
Xcode 10.1 10B61

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• checked your Portfile with port lint?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?

[macportsbot]

Travis Build #4402 Passed.

Lint results

--->  Verifying Portfile for gitlab-runner
--->  0 errors and 0 warnings found.

Port gitlab-runner success on xcode9.4. Log
Port gitlab-runner success on xcode8.3. Log
Port gitlab-runner success on xcode7.3. Log
Port gitlab-runner success on xcode10.1. Log

[pmetzger]

This would seem to just install a binary? What's the source written in?

[breun]

Yes, this installs a binary.

I believe it’s written in Go, but I’m not familiar with that: https://gitlab.com/gitlab-org/gitlab-runner

[pmetzger]

We usually have a very strong preference not to just install binaries except for some Java code where it's hard to do otherwise. Perhaps it would be possible to build this instead? We have a substantial Go build support infrastructure now.

[breun]

I'm sure it's possible, but I don't have the time right now to redo this port as a build from source. I personally don't care about building from source, because of the build time and the extra dependencies that need to be installed to build from source.

[pmetzger]

You might not care, but MacPorts generally does care, both for reasons of provenance and to assure compatibility with older versions of MacOS. You might ask on the developers list for assistance so you don't have to figure the whole thing out alone.

[nerdling]

Looks like documentation on what's needed is here:
https://docs.gitlab.com/runner/development/

[macportsbot]

Travis Build #4530 Passed.

Lint results

--->  Verifying Portfile for gitlab-runner
--->  0 errors and 0 warnings found.

Port gitlab-runner success on xcode9.4. Log
Port gitlab-runner success on xcode8.3. Log
Port gitlab-runner success on xcode7.3. Log

[macportsbot]

Travis Build #4531 Passed.

Lint results

--->  Verifying Portfile for gitlab-runner
--->  0 errors and 0 warnings found.

Port gitlab-runner success on xcode9.4. Log
Port gitlab-runner success on xcode8.3. Log
Port gitlab-runner success on xcode7.3. Log

[pmetzger]

I'll repeat that this really should be building the binary locally; we have a very strong preference for that, and we have all the tools needed in the go portgroup.

[breun]

@pmetzger That's fine, but I don't know how. I asked on the macports-dev mailinglist and somebody gave it a go, but also didn't get it to work, so currently either this gets merged and MacPorts has gitlab-runner or this doesn't get merged and MacPorts doesn't have gitlab-runner. Or we wait some more until someone does create a working Portfile that builds from source.

[pmetzger]

@amake can you be of some help here?

[amake]

Done. You will probably want to squash my second commit into @breun's first commit.

Note that upstream wants to put a bunch of build metadata into the binary: version, git revision, git branch, and build date/time. I've turned all of these (except version) into the string "unknown" but if you want to do them right:

• git revision, git branch: switch to fetch.type git and shell out as in the upstream Makefile to get these values
• build date/time: since this is guaranteed to make the build non-reproducible, do we even want this? If desired you can get it the same way they do in their Makefile.

[pmetzger]

I think build dates and times being burned into binaries is a bad idea, so no on that.

@breun so does this help?

[breun]

@amake Thanks a lot for looking into this! I just successfully built gitlab-runner via MacPorts on my local machine:

$ gitlab-runner -v
Version:      11.5.1
Git revision: unknown
Git branch:   unknown
GO version:   go1.11.2
Built:        unknown
OS/Arch:      darwin/amd64

I think leaving the 'unknown' entries is fine.

@pmetzger This definitely helps and I think I could be the maintainer from this point on, so I'd be fine with merging.

[pmetzger]

Merged. Thanks, @breun and @amake!