Deprecate service's management and `exec` commands

If we decide to go this way, when should we remove the features? Are 3 months enough time to make users aware of this?

If gitlab-runner (start|stop|install|uninstall|status) is removed I hope the replacement is just as easy to use.

I propose to deprecate them now. We will see what will be a response from the community after doing that.

@bbodenmiller If you install runner from the package, it will already have all service controls with it.

Is there a replacement for gitlab-runner exec? I've found it very useful for testing CI configs locally and the current instructions for testing a job locally seem overly complicated and didn't work when I tried (go was missing from Docker image).

@tamlyn Not at this moment. We have few problems with the exec command that make it not following all of the .gitlab-ci.yml features. Current architecture of this command is hard to maintain and that's why we decided to deprecate this. It will not be removed immediately in %10.0, but we will remove it in near future.

mentioned in issue #2732 (closed)

@tamlyn We might re-work that in slightly different form, but today I agree with @tmaczukin that we are unable to maintain the exec feature set to be on-pair with GitLab.

mentioned in issue #2752 (closed)

changed the description

mentioned in merge request !679 (merged)

closed via merge request !679 (merged)

@tmaczukin @ayufan @bikebilly generally we don't deprecate something until it has been replaced. Why deprecate now? It's still useful functionality.

We cannot maintain today the functionality provided by exec without significant commitment. One of the reasons for deprecating is let people understand that this is not maintained a way of executing. We might or not replace that with better equivalent, but this is not granted.

mentioned in issue #2784

exec is a feature of major importance IMO. Please provide a replacement!

I agree that exec is essential and that it currently sux. Bunch of developers in my team struggle with simulating stuff on the build server directly with it now, and without it its even worse.

I agree that service functions should be removed.

As alternative on Windows, the one can use nssm (used for example by rundeck). Since it is available on Chocolatey, I can add it as a dependency to gitlab-runner and provide the same usage as before via package arguments:

PS: Unrelated to this, 10.0.0-rc.1 is not valid semantic version - pre releases shouldn't have dot. You should have used 10.0.0-rc1.

It's a shame that exec is going out the window. It does have limitations, some of them major, like the Git-requirement, but I personally use it to avoid having to duplicate build scripts.

A replacement would be highly appreciated.

Right now I can setup a Windows build node by dropping an appropriate config.toml in a directory, dropping the gitlab runner EXE next to it, and running gitlab-runner-windows-amd64.exe install.

Going forward I will have to get the config and the runner, drop them in a directory, then install chocolatey, then install nssm via chocolatey. I also have to figure out how chocolatey and nssm work and how to make the gitlab runner work via nssm. Since I'm inside a corporate, I have to get permission to install those two extra dependencies. Since our gitlab runner boxes are isolated from the Internet (see: inside a corporate), I have to get our operations team to put them on the internet long enough for me to install chocolatey/nssm. And then there's the issue of keeping those dependencies up-to-date as well as the runner.

Are you seeing the difference here? Are you seeing how making the runner less easy to use is a problem? Especially considering you've provided zero rationale as to why you're making it less easy to use?

If you want people, especially enterprises, to NOT use your software, you're going about it exactly the right way.

@IanKemp

Going forward I will have to get the config and the runner, drop them in a directory, then install chocolatey, then install nssm via chocolatey.

There is nothing to figure out, it just works

iwr https:\\chocolatey.org\install.ps1 | iwr   # install choco
cinst gitlab-runner --params /Service          # install runner and its deps

This installs all other tools that are required (git, eventually nssm etc.).

Now adding autologon param that can be used instead of a service and when GUI is required:

cinst gitlab-runner --params '/Autologon:gitlab-runner:<pass>'`

Since our gitlab runner boxes are isolated from the Internet (see: inside a corporate)

You can use choco packages offline and from within private repository or just keep them on SMB share (and perhaps update them from location that has access to internet)

And then there's the issue of keeping those dependencies up-to-date as well as the runner.

No issue here:

choco upgrade gitlab-runner

will update runner and its dependencies.

If you want people, especially enterprises, to NOT use your software, you're going about it exactly the right way.

I use this exclusively in enterprises (even with proxies, even without internet) :) As a bonus, you may want to depend on particular version of runner, for instance the one that does not deprecate: cinst gitlab-runner --version 9.5.0

exec is key to test local changes in .gitlab-ci.yml easily and closer to real execution. +1 for a replacement.

mentioned in issue fdroid/fdroid-website#142

added Documentation and removed ~60197 labels

Deprecate service's management and `exec` commands

Actions

Designs

Child items ...

Activity

Admin message

Admin message

Deprecate service's management and `exec` commands

Actions

Relates to

Activity