Interactive web terminals for Shell and Kubernetes Runners
Interactive web terminals for Shell and Kubernetes Runners
CI/CD jobs are executed by runners based on the configuration provided by users in their pipeline definition. But this execution is not interactive and, if it fails, users cannot dig into details to spot the possible source of the problem. Interactive web terminals bring the capability to connect to a running or completed job and manually run commands to better understand what’s happening in the system.
Improve includes in .gitlab-ci.yml
for reusing scripts
.gitlab-ci.yml
for reusing scriptsImprove includes in .gitlab-ci.yml
for reusing scripts
Reusing CI/CD process code is a great practice to help ensure
consistency in software delivery, and minimizes the amount of per-job
scripting that’s needed to write and maintain. We now offer a flexible,
powerful approach for code reuse in templates using YAML extends
keywords.
Include private contributions in user contribution graph
Include private contributions in user contribution graph
At GitLab, we love open source! But sometimes you want to work on a private project you don’t want to share (yet), or you are constrained for confidentiality reasons. In any case, GitLab has got you covered.
With this release, we are introducing the option to include private contributions in your profile’s contribution graph. Contributions to private projects are now displayed in the contribution graph and contributions of this day if you enable this setting for your profile. This way, your active work on private GitLab projects is represented accurately, without giving away any private details.
Thank you George Tsiolis for your contribution!
Redesigned project overview
Redesigned project overview
Iterating on our user interface is a constant focus for improving our product.
With GitLab 11.3, we are updating the UI of the project overview page to allow for a better experience when exploring projects. Besides improving the overall information structure of this page, we are left-aligning the top header section and optimizing the vertical spacing, so you can get a quicker overview about the project and its content.
Protected Environments
Protected Environments
Operators are often responsible for the sensitive task of protecting the environments we deploy code to on a daily basis. This task becomes particularly important when deploying code to a production environment.
With Protected Environments, operators obtain full control around which person, group, or account is allowed to deploy to a given environment, allowing further protection and safety of sensitive environments.
Code Owners
Code Owners
Code review is an essential practice of every successful project, but who should review the changes is not always clear. GitLab now supports assigning code owners to files to indicate the team members responsible for code in your project.
Code owners are assigned using a file named CODEOWNERS
, a format
similar to gitattributes
,
and are listed below the commit details when viewing a file in GitLab.
In upcoming releases, Code Owners will be integrated into the merge request workflow to suggest approvers, assign approvers, and enforce code owners.
Epic forecasting with integrated milestone dates
Epic forecasting with integrated milestone dates
Prior to this release, you could set fixed values for the planned start date and the planned end date of an epic. This is useful for high-level planning of epics, and tracking them over time. However, as issues are attached to the epic, and the issues are scheduled for work with actual milestones, it would be useful to have the epic dates reflect those milestones.
With this release, you can easily switch from the fixed value for either of
the dates, to a dynamic value called From milestones
. For the planned
start date, this dynamic value will take on the earliest start date of all
milestones assigned to the epic’s attached issues. This is truly dynamic
in that it will change if issues are added or removed, if milestones are
assigned or unassigned (to those issues), or if the start dates are changed
for those milestones. The dynamic version of the epic’s planned end date
is analogous.
This feature is useful if you want to seamlessly transition from high-level, top-down planning to micro-level, bottom-up planning. See more in a blog post on the Epics roadmap that we published about this a few weeks back.
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