Commit fd4f4ce1 authored by Mark Pundsack's avatar Mark Pundsack

Cleanup

parent 8fc6bfc9
Pipeline #15152660 passed with stages
in 9 minutes and 5 seconds
......@@ -126,7 +126,6 @@ features:
reporter: bikebilly
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/38962'
description: | # supports markdown
In GitLab 10.0 we released Auto DevOps (still in Beta) and users can
enable it for their projects, but the first pipeline, and thus the first
deployment to production, doesn't happen until the first push after
......@@ -144,12 +143,15 @@ features:
reporter: bikebilly
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/34834'
description: | # supports markdown
When dealing with CI/CD pipelines, it is quite common that artifacts are created in one job
and then used later by another one. Using the `dependencies` keyword, you can explicitly list
which artifacts from previous stages you need.
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 erased.
In GitLab 10.3, we introduce a strict checking on dependencies, and the job fails if they
cannot be found, for example if they are expired or have been erased.
In GitLab 10.3, we introduce strict checking on these dependencies, and
jobs will fail if their dependencies cannot be found.
- name: Only job owners can delete logs
available_in: [ce, ees, eep] # required
......@@ -158,12 +160,14 @@ features:
reporter: bikebilly
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/31771'
description: | # supports markdown
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.
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 and limit access for unauthorized users.
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.
- name: Git push & pull on project redirects
available_in: [ce, ees, eep] # required
......@@ -172,17 +176,16 @@ features:
reporter: mydigitalself
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/35385'
description: | # supports markdown
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. The same
has not been true for git actions.
From GitLab 10.4, git actions will now redirect too! This means that any build scripts,
automation or developer git clients will continue to work after a rename, making any
transition a lot smoother.
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. The same has not been true for git actions.
Please note, to avoid pulling from or pushing to an entirely incorrect repository the
old path will be reserved.
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
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.
- name: Show project member role on list of projects
available_in: [ce, ees, eep] # required
......@@ -192,9 +195,9 @@ features:
reporter: mydigitalself
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/27742'
description: | # supports markdown
GitLab's Project Dashboard is a great place to view all of the projects you belong to.
This page now displays your level of permission next to each project, so you
know exactly what your role is.
GitLab's Project Dashboard is a great place to view all of the projects
you belong to. This page now displays your level of permission next to
each project, so you know exactly what your role is.
- name: New project customizable help text
available_in: [ce, ees, eep] # required
......@@ -204,12 +207,13 @@ features:
reporter: mydigitalself
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15541'
description: | # supports markdown
With thanks to our community contributor, [Markus Koller](https://gitlab.com/toupeira),
it is now possible to add your own help text on the new project page.
With thanks to our community contributor, [Markus
Koller](https://gitlab.com/toupeira), it is now possible 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.
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.
- name: User and group additions to protected branch API
available_in: [ce, ees, eep] # required
......@@ -218,12 +222,15 @@ features:
reporter: mydigitalself
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/27742'
description: | # supports markdown
[Protected branches](https://docs.gitlab.com/ee/user/project/protected_branches.html) allow
you to lock down push or merge access to your repository's branches,
preventing inadvertent changes entering your code or enforcing particular workflows.
[Protected
branches](https://docs.gitlab.com/ee/user/project/protected_branches.html)
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 has now been made available by the API.
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.
- name: Comment on commits in merge requests
available_in: [ce, ees, eep] # required
......@@ -233,14 +240,16 @@ features:
image_url: '/images/10_3/comment_commit_mr.png'
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/31847'
description: | # supports markdown
Prior, you could comment on commits, apart from merge requests. You could comment on the entire
commit, or just in a particular file diff on the commit. With this release, you can now comment on a commit
within the context of a merge request itself. Simply navigate to the commits tab of the merge request,
click on a commit, which will then bring you to the changes tab, with a new interface
that allows you to have a resolvable discussion with respect to a particular commit
in that merge request. That discussion is also shown in the discussion tab. This feature
is especially useful for teams with commit-based workflows, instead of merge request
version workflows.
Prior, you could comment on commits, apart from merge requests. You
could comment on the entire commit, or just in a particular file diff on
the commit. With this release, you can now comment on a commit within
the context of a merge request itself. Simply navigate to the commits
tab of the merge request, click on a commit, which will then bring you
to the changes tab, with a new interface that allows you to have a
resolvable discussion with respect to a particular commit in that merge
request. That discussion is also shown in the discussion tab. This
feature is especially useful for teams with commit-based workflows,
instead of merge request version workflows.
- name: Navigate to containing epic from issue
available_in: [eeu] # required
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment