This commit adds pipeline.type key to PipelineEntity.
This key will be used in MR widget in the next iteration.

This method will be overridden in EE

Instead of highlighting all lines when not all of them
are needed, only highlight from the beginning up to
the specified limit.

The `BlobPresenter#highlight` method has been updated
to support `to` param. This param will be used to limit
the content to be highlighted.

Peter Leitzen authored 5 years ago and Thong Kuah committed 5 years ago

The virtus project has been discontinued:

https://github.com/solnic/virtus/commit/a6f896984

- expand upwards
- expand downwards
- expand all

in both inline and parallel views

Igor Drozdov authored 5 years ago and Douwe Maan committed 5 years ago

Splits auto-refreshing of MR widget into 2 requests:

- the one which uses etag-caching and invalidates the fields on change
- the one without caching

The idea is to gradually move all the fields to etag-cached endpoint

This reverts merge request !31361

Instead of highlighting all lines when not all of them are
needed, only highlight specific lines.

The `BlobPresenter#highlight` method has been updated to
support `since` and `to` params. These params will be used to
limit the content to be highlighted.

Modify `Gitlab::Highlight` to support `since` param which will
then be used to determine the starting line number.

This commit changes how we eager-load projects, routes, and namespaces
required by the deploy keys endpoint, getting a 10x improvement in my
local testing.

The endpoint still doesn't scale in-general, but going from ~13 seconds
to dump a 63K result to generating the same thing in ~1.6 seconds seems
like a good improvement to me.

Return the `text` as plain string in the response instead of
including HTML tags but keep `rich_text` as is.

The fix is to modify `Blob::UnfoldPresenter#diff_files` to map
each raw diff line (limited by the range specified) to a
corresponding line in an array of highlighted lines to use as
`rich_text`.

The current approach requires catching exceptions to handle these errors
and callers are already handling model validations so it seems more
appropriate.  Also it seemed to convoluted to add this logic directly to
the model since the model needs to check too many possible associations
to determine whether or not there are more than one cluster since the
model doesn't know what it's being created on. Additionally we only
wanted to validate during create to avoid the risk of existing models
becoming invalid by many different edge cases.

Adding new `AddAwardEmoji`, `RemoveAwardEmoji` and `ToggleAwardEmoji`
GraphQL mutations.

Adding new `#authorized_find_with_pre_checks!` and (unused, but for
completeness `#authorized_find_with_post_checks!`) authorization
methods. These allow us to perform an authorized find, and run our own
additional checks before or after the authorization runs.

https://gitlab.com/gitlab-org/gitlab-ce/issues/62826

Enable Get and Update of ci_default_git_depth for
Project API.

Renaming Project#default_git_depth to :ci_default_git_depth
to give more context through the API usage.

Add API documentation

Krasimir Angelov authored 5 years ago and Fabio Pitino committed 5 years ago

Introduce default_git_depth in project's CI/CD settings and set it to
50. Use it if there is no GIT_DEPTH variable specified. Apply this
default only to newly created projects and keep it nil for old ones
in order to not break pipelines that rely on non-shallow clones.

default_git_depth can be updated from CI/CD Settings in the UI, must be
either nil or integer between 0 and 1000 (incl).

Inherit default_git_depth from the origin project when forking projects.

MR pipelines are run on a MR ref (refs/merge-requests/:iid/merge) and it
contains unique commit (i.e. merge commit) which doesn't exist in the
other branch/tags refs. We need to add it cause otherwise it may break
pipelines for old projects that have already enabled Pipelines for merge
results and have git depth 0.

Document new default_git_depth project CI/CD setting

We have one auto merge strategy today - Merge When Pipeline
Succeeds.

In order to add more strategies for Merge Train feature,
we abstract the architecture to be more extensible.

Removed arguments

Fix spec

This file conflicts quite frequently with any changes in the file.

and allow passing of child_complexity to the
'resolver_complexity' metho

The ref to the branch was being displayed as
raw HTML in the Pipelines page

Since label presenter is used in label index view, label class
check doesn't work as expected because the class is now LabelPresenter.

Also `label.subject` doesn't work as expected now because Label's model
`subject` method is shadowed by Gitlab's presenter's method which uses
`subject` for referencing the original object.

Instead we use a presenter's method for both checks now.

`label_deletion_confirm_text` is not used anywhere so it's removed

Added a changelog entry for the feature

Instance level clusters were already mostly supported, this change adds
admin area controllers for cluster CRUD

Peter Leitzen authored 5 years ago and Bob Van Landuyt :neckbeard: committed 5 years ago

Tweak cluster helper and refactor its specs.

Source branch can be removed after the merge and
we have to make sure to avoid rendering links if it's the case.

When rendering a label we want to check 'scoped_label' feature
availability on a project/group where label is being used. For
this reason a label presenter is used in UI and information about
context project/group is passed to this presenter.

- app/services
- app/controllers
- app/presenters

This commit adds two new warning messages to the MR widget that handle
cases involving merge request pipelines.

This will allow to user the term managed? on
https://gitlab.com/gitlab-org/gitlab-ce/issues/56557. Managed? will be
used to distinct clusters that are automatically managed by GitLab

By using `refs/merge-requests/:iid/head`

ok

ok

Improve naming nicely

Add nice tests

add nice tests

fix some more

revert

Introduces the concept of Prerequisites for a CI build.
If a build has unmet prerequisites it will go through the
:preparing state before being made available to a runner.

There are no actual prerequisites yet, so current
behaviour is unchanged.

Commit changes

Add spec

Add changelog

fix

fix

Fix

Fix spec

Finish spec

ok

nice

ok

ok

ok

fix