Use heptapod prefix for default configuration directory
Merge request reports
Activity
Hi, thanks for the suggestion.
This is something I've been hesitating a lot about when the Heptapod Runner fork started. As you can see, I did nothing then to change it.
On one hand, you are obviously right that it is more natural this way.
On the other hand, this makes a divergence from upstream, making Heptapod Runner less of a drop-in replacement for GitLab Runner: switching users using the default location would have to move their configuration file or start pointing at it explicitly.
For perspective, Heptapod Runner can work against an upstream GitLab instance.
I'm still hesitating, will have to decide when back from leave.
@raphael.gomes or @franckbret if you have advice on this?
I'm leaning towards going with this.
One additional reason besides @ced opinion (as stated by submitting this MR) is that it'd be necessary for easy packaging in distributions (see #6). Of course, in the case of Debian, we could add conflicts markers, but there could be legitimate reasons to have both GitLab Runner and Heptapod Runner on the same system (currently the wide gap in versions would be one).
added 1658 commits
-
b3ea0ff5...4987077f - 1657 commits from branch
branch/heptapod
- 0cadf93201aa - Use heptapod prefix for default configuration directory
-
b3ea0ff5...4987077f - 1657 commits from branch
added 2 commits
- df248338ab4d - configuration: less hardcoding of /etc/gitlab-runner
- 850c2290a23f - Use heptapod prefix for default configuration directory
added 17 commits
-
850c2290...6fee0495 - 15 commits from branch
branch/heptapod
- d29db1d51b99 - configuration: less hardcoding of /etc/gitlab-runner
- 2141e51bccc9 - Use heptapod prefix for default configuration directory
-
850c2290...6fee0495 - 15 commits from branch
and I could use the Docker image built by the
pkg-amd64
job work for good on my testing project.That's enough for now. @ced will be in version 0.7.0