GitLab

 Rename column in the database
 Rename fields related to import/export feature
 Rename API endpoints
 Rename documentation links
 Rename the rest of occurrences in the code
 Replace the images that contain the words "build succeeds" and docs referencing to them
 Make sure pipeline is green and nothing is missing.

updated doc images

renamed only_allow_merge_if_build_succeeds in projects and fixed references

more updates

fix some spec failures

fix rubocop offences

fix v3 api spec

fix MR  specs

fixed issues with partials

fix MR spec

fix alignment

add missing v3 to v4 doc

wip - refactor v3 endpoints

fix specs

fix a few typos

fix project specs

copy entities fully to V3

fix  entity error

more fixes

fix failing specs

fixed missing entities in V3 API

remove comment

updated code based on feedback

typo

fix spec

From the Ruby style guide:

    # bad
    class FooError < StandardError
    end

    # okish
    class FooError < StandardError; end

    # good
    FooError = Class.new(StandardError)

This cop does that, but only for error classes (classes where the
superclass ends in 'Error'). We have empty controllers and models, which
are perfectly valid empty classes.

add /award slash command; Allow posting of just an emoji in comment

Fix broken test

Add endpoint to stop an environment through the API.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Previously it was listening for focusout, it now listens for blur &
paste events

Closes #28436

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

- Moves a duplicate `file_storage?` definition into the common
  `GitlabUploader` ancestor.
- Get the `uploads` base directory from a class method rather than
  hard-coding it where it's needed. This will be used in a subsequent MR
  to store Uploads in the database.
- Improves the specs for uploaders.

Previously, we created an unmergeable todo when a merge request:

1. Had merge when pipeline succeeds set.
2. Became unmergeable.

However, when merge when pipeline succeeds fails due to unmergeability,
the flag isn't actually removed. And a merge request can become
unmergeable multiple times, as every time the target branch is updated
we need to re-check the mergeable status. This means that if the todo
was marked done, and the MR was checked again, a new todo would be
created for the same event.

Instead of checking this, we should create the todo from the service
responsible for merging when the pipeline succeeds. That way the todo is
guaranteed to only be created when we care about it.