But while renaming we should remember about compatibility. For example, to reverse /usr/bin/gitlab-runner -> /usr/bin/gitlab-ci-multi-runner symlink in DEB/RPM packages (so existing scripts will still work).
I would also fix a behavior of systemd/upstart/sysv scripts to make them to be provided by us, instead of being generated by runner during install.
It allows then these scripts to be user-managed, otherwise we overwrite it in each release.
Should we with 10.0 kill some of the features of a runner?
gitlab-runner exec: which is today hard to maintain, and without serious redesign it is effectively not working as expected,
gitlab-runner start/stop/install/uninstall/status: which is effective service management, I know that we ask to run these commands on Linux/Windows/OSX, but maybe we would be better to refer to external tools instead and make runner a bare executable that relies on prepared configurations?
@bikebilly I've created #2709 and #2710 (closed) which will track the ideas. Let's leave this issue for only renaming gitlab-ci-multi-runner to gitlab-runner :)
cleanup gitlab-ci-multi-runner-downloads bucket (we should remove all branch related directories and leave only latest and tagged versions)
Few more words about the https://packages.gitlab.com/runner/stable-10 repository idea. When we've switched from 1.x to 9.x version we introduced a big breaking change - Runner < 9.0 was not working with GitLab >= 9.0, Runner >= 9.0 was not working with GitLab < 9.0. Some users were not aware of this and have their system configured to automatically update packages. This ended with a non-working CI environment. One of propositions how we could prevent such situation was to introduce a new repository for each major version. This mean that for Runner 10.0 we should switch to something like gitlab-runner-10 or stable-10 and use it for all 10.x.y versions, but when we decide to release 11.0 - switch to gitlab-runner-11 or stable-11 and use it for all 11.x.y versions.
Such approach is not uncommon and is used by many projects. But of course this will require manual action to upgrade to new major version. However - in my opinion - such disadvantage is a fair cost of preventing a situation when CI environments stops working because some package was autoupdated to a non-compatible version.
@ayufan I think I've listed all steps that we were talking about. Please take a look and post any comments if needed. When we'll agree that the plan is OK, I'll move it to issue's description.
This ended with a non-working CI environment. One of propositions how we could prevent such situation was to introduce a new repository for each major version. This mean that for Runner 10.0 we should switch to something like gitlab-runner-10 or stable-10 and use it for all 10.x.y versions, but when we decide to release 11.0 - switch to gitlab-runner-11 or stable-11 and use it for all 11.x.y versions.
If we use the same repository and ask all users to upgrade now to gitlab-runner it should work now fine, as packages should not self-upgrade if we make gitlab-runner to not provide gitlab-ci-multi-runner.
@ayufan We still need to change the name of the repository as part of this issue. Currently it's named packages.gitlab.com/runner/gitlab-ci-multi-runner and to be consistent with the rest of project we should rename it at least to packages.gitlab.com/runner/gitlab-runner.
What you're proposing will work, but only for 9.x->10.x switch. My proposition was for a future releases. If with 11.0 we again release something that is not working with older versions of GitLab, then automatic upgrade will generate a problem. We can leave this as it is (and suggest uses to not configure auto upgrades) or prevent problems from happening with having a new repository for each new major release.
However, let's switch now to packages.gitlab.com/runner/gitlab-runner and leave a decision if we wan to have a new repository for a major release for 11.x (then, if needed, we can create packages.gitlab.com/runner/gitlab-runner-11).
For the same reason, we don't have gitlab-ce-11.0. Having automated updates is just asking for problems. People may configure their systems to prevent an update from 10.x and 11.x, we should not be too clever I believe.
@ayufan In the checklist I've added a step push container images to https://gitlab.com/gitlab-org/gitlab-runner/container_registry but at this moment I started to think if we really should do this. Old images are available from the old repository path and the only two that are required to be available in this project - at this moment - are ci-1.8 and /alpine-no-root:latest which are used by our CI/CD Pipelines.
There are a boatload of google search results relating to issues with the runner/ci usage in general which are now 404ing. Maybe a server side redirect can be added?
I don't think that doing server side redirect is a good idea, as this is not maintainable.
I now think that we might need to revert the rename and create a new project instead. Instead just move all relevant issues from gitlab-ci-multi-runner to a new project.
The problem is with a bunch of links, like issues or merge requests, everywhere across gitlab, as they are simply not being rewritten.