Automatically run first pipeline when enabling Auto DevOps
Previously in GitLab if you enabled Auto DevOps you still had to wait until
you pushed a commit before your pipelines would populate.
This was a confusing experience that didn’t follow expected behavior.
With GitLab 10.3, a pipeline for your project will be run as soon as you
enable Auto DevOps in Settings, so you can immediately see results without
needing to push another commit to your code.
Restricted deletion of CI/CD job logs
When running a job as part of a CI/CD pipeline, the job log is stored in
GitLab and is available for further analysis to users that have access
to the project. It can be also erased in order to avoid information
leaks or to free up space.
With GitLab 10.3, only Masters and the user that triggered the job are
authorized to erase the job logs; enforcing a more consistent permission
model.
Git push and pull on project redirects
Renaming and moving projects happens all the time. GitLab’s web user
interface has always redirected people from the old location to the new
location, but the same has not been true for Git actions.
From GitLab 10.3, Git actions will now redirect too! This means that any
build scripts, automation, or Git clients will continue to work after a
user or group rename, making any transition a lot smoother.
Please note, to avoid pulling from or pushing to an entirely incorrect
repository, the old path will be reserved.
Customize “New Project” page
With thanks to our community contributor, Markus
Koller, it is now possible for GitLab
administrators to add your own help text on the “New Project” page.
This is a great way to provide additional instruction to users on how
projects should be created. As this text supports Markdown, you can link
to any further pages or documentation to provide additional help.
Navigate to epic from issue
Since issues can only belong to one epic, when looking at an issue it’s useful to know if
it already belongs to an epic. The containing epic of an issue now appears in the issue
sidebar as a link, allowing you to quickly navigate to it.
Render links to epics in GitLab Flavored Markdown (GFM)
Links to epics in GitLab Flavored Markdown (GFM) textboxes will now be
rendered similar to issues, merge requests, and other objects in GitLab.
The group path is shown followed by &, and then the epic ID. A helpful
tooltip shows the epic title. This allows you to paste a link to an epic
in a textbox, and GitLab will render it more compactly and in a more readable fashion.
You can also directly enter the shorthand for the epic reference in the GFM field, such as
gitlab-org&23, and GitLab will turn that into link.
Sort milestones on group milestone list
You are now able to sort milestones on the group milestone list page,
similar to the project milestones list page. We introduced group
milestones a few releases ago and are working to bring features from
project milestones to group milestones.
Thank you George Andrinopoulos for the contribution!
Smarter autocomplete for label quick action
When using quick actions to add or remove labels to an issue or merge
request, the autocomplete dropdown is extremely helpful to quickly find
what you are looking for. With the latest change, autocomplete is even
smarter so that when adding a label, the dropdown doesn’t show labels
that are already added. And when removing a label, the dropdown only
shows labels that are already added.
Thank you blackst0ne for the
contribution!
Total issue time spent in milestone
Many teams track how much time is spent working individually on issues.
With this latest change, you can now see how much time is spent on all
of the issues in a single milestone, summed up together, in the sidebar
of the milestone page.
Thank you George Andrinopoulos for the
contribution!
Trigger pull mirroring via API
Pull mirroring, when enabled for a repository, automatically mirrors
changes from the configured upstream Git repository to your repository.
Changes are mirrored regularly when they are detected by polling.
A new API has been added to trigger changes to be pulled immediately.
When used with a push event webhook from the upstream repository, pull
mirroring can happen within seconds.
Restrict Repository Mirroring to admins
Push and pull mirroring, when enabled for a repository, will
automatically mirror to or from the configured target Git repository.
In GitLab 10.3 push mirroring can be restricted to admins. Now admins
can limit access to push and pull mirroring to only admin users, to
prevent repositories being replicated to or from a GitLab instance.
Simplified PostgreSQL HA configuration
In GitLab 10.2 Postgres HA became generally available, making it easy to set up a production Postgres database cluster using our Omnibus package.
Now we are making it even easier with the introduction of new Postgres roles. These roles significantly reduce the configuration required to set up standalone database nodes, by automatically turning off all other features and components.
GitLab Runner 10.3
We’re also releasing GitLab Runner 10.3 today! GitLab Runner is the open
source project that is used to run your CI/CD jobs and send the results
back to GitLab.
Most interesting changes:
List of all changes can be found in GitLab Runner’s CHANGELOG.
Handling oudated replicas with database load balancing
The database load balancer included in GitLab Enterprise Edition has
been improved so it can handle replicas that are lagging behind too
much. This has been combined with adjustments to the replica status
checks to reduce the number of queries necessary to check if a replica
is available.
These changes allow the database load balancer to stop sending read-only
queries to replicas when those replicas are lagging behind with
replicating data from a primary.
For more information check the merge request on
how we handled outdated replicas in the DB load balancer.
Strict check on artifacts dependencies
When dealing with CI/CD pipelines, it is quite common that artifacts are
created in one job and then used later by another job. Using the
dependencies keyword, you can explicitly list which artifacts from
previous stages you need. But when jobs are retried some time later,
those artifacts may no longer exist, for example if they have expired or
have been manually erased. This could lead to inconsistent states where
code is expecting to find resources that are not available, creating
errors that are hard to spot and debug.
In GitLab 10.3, we introduce strict checking on these dependencies. Since
jobs will fail if their dependencies cannot be found, you’ll always be aware
if something required is missing. This allows you to take proper actions
to solve the problem, for example running a brand new pipeline from scratch.
Improved integration with existing clusters (Beta)
Until now, configuring a project to use an existing Kubernetes cluster
(as opposed to creating a new cluster) relied on the service integration
page in the project settings. This made the flow inconsistent with the
first-class support for Clusters introduced in GitLab 10.1.
GitLab 10.3 adds the ability to add existing Kubernetes clusters to a
project, directly from the Clusters page, and deprecates the old service
integration page.
Show project member role on list of projects
When working with multiple projects, sometimes it’s difficult to remember what
permissions you have for each project. This can lead to frustrating situations and
not knowing why certain features aren’t available.
Having a quick reference that tells you what permission level you have helps you understand
your limitations and lets you act within them or request escalated privileges when appropriate.
Now you can see your permission level on the GitLab Project Dashboard next
to the project name. You no longer have to click into each project and
dig into the users page to find this info.
User and group additions to Protected Branch API
Protected
branches
allow you to lock down push or merge access to your repository’s
branches, preventing inadvertent changes entering your code or enforcing
particular workflows.
One great feature of protected branches is to specify users or groups
that do have permission to push or merge changes. This is now available
in the API.
Attach images to epics
You can now attach images (or any file) to an epic, via the epic
description, just like in an issue description (and other Markdown
boxes in GitLab). This allows you to be even more descriptive in
documenting epics, such as by including inline wireframes and mockups.
Update issue weight from Issue Board sidebar
You are now able to update an issue’s weight right from an issue board’s
sidebar, exactly the same as in the issue page itself. This allows you to
quickly and more fully manage issues when doing planning and tracking
from within a board.
Redesigned merge request diff file navigation
The merge request diff file navigation has been redesigned to more
clearly show the file name in its own line. The file path is also now
truncated at the start if it is too long.
Create merge request through email
Some people prefer doing development as much as possible using their desktop
tools, reserving their use of the GitLab web interface for tasks which are
absolutely necessary there.
With today’s release, you can now create merge requests through email, expanding
the breadth of developer-focused features you can use with your existing tools.
Send an email to GitLab, specifying the source branch name in the email subject
line, and GitLab will automatically create the merge request for you. Find the
special (and unique-to-you) email address for a given project by clicking the link
at the bottom of the project merge requests page. It doesn’t change (unless you refresh it).
So you can safely save it in your email client.
For developers who do development, Git, and email all inside a terminal, you can now
do everything up to creating a merge request all without leaving that terminal.
Only mirror protected branches
Pull and push mirroring, when enabled for a repository, will
automatically mirror to and from the configured target Git repository.
But this fails if any pushes contain altered Git history, such as by
rebasing. It’s normally not a good idea to rebase certain key branches,
like master, but it’s more common for feature branches.
To prevent rewritten history from a feature branch causing mirroring to
fail, mirroring can now be limited to only protected branches.
Immediate push mirroring
Push mirroring, when enabled for a repository, will automatically
push changes to the configured downstream Git repository.
The rate limit has been updated to push changes immediately, but is
limited to one push every five minutes. If mirroring is limited to
protected branches, the rate limit is decreased to one push every
minute.
Improved Geo nodes dashboard
Managing and monitoring of Geo nodes is improved by separating the
monitoring interface from the process of adding and editing a Geo node.
Omnibus improvements
- Additional warnings have been added for deprecated settings, and they now appear in red.
- gpgme 2.1.15 is now packaged with Omnibus GitLab, making it easier to use signed commits.
- Git has been updated to 2.14.3
- Docker Registry has been updated to 2.6.2
- Redis has been updated to 3.2.11
Performance improvements
We are continuing to make great strides in improving
the performance of GitLab in every release.
We’re committed to not only
making individual instances of GitLab even faster,
but also to greatly improving the performance of GitLab.com,
an instance that has over one million users!
In GitLab 10.3 we are shipping 24 performance improvements for merge
requests, CI/CD, Prometheus, frontend, and a lot more! Some of the
noteworthy improvements include:
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback