Today we release a new version of GitLab CI. We have done a lot of work to improve the flexibility of the architecture. In addition this release contains bug fixes and UI improvements.
It is no longer necessary to manually copy a token from GitLab CI to the corresponding GitLab instance; GitLab CI will do this for you. This means that it now only takes one click in GitLab CI to enable builds for your GitLab project! Just click the 'Add' button next to your project on the GitLab CI Dashboard and you are ready to set up your build script.
GitLab CI 4.0 restricts certain privileges to users who have Administrator rights on the corresponding GitLab server. Only administrators can manage runners now.
In addition, administrators can list and remove projects.
From now on a runner can be in one of two states: 'shared' or 'specific'. By default every runner is 'shared' and will run builds for any project. After a runner is assigned to a project it becomes 'specific' and it will exclusively run builds for that specific project.
We re-designed the build page a bit to concentrate more on build output, moving all additional information to right-hand side.
Now you can choose the method of fetching new code for each repeat build. Before we used
git fetch but if you want to use
git clone it is now available as a radio button in the project settings screen. It can be useful to use
git clone if your project directory changes state during the build and you want to have a clean directory for each build.
We have also made small improvements to the profile page.
GitLab CI 4.0 requires GitLab 6.3 or higher - - -