Enable the Rubocop DeprecatedClassMethods cop
This reports uses of `File.exists?` and `Dir.exists?`, which were both
deprecated in Ruby and will eventually be removed in favor of `.exist?`.
Also fixes all existing uses of the deprecated methods.
See merge request !4087
In 8278b763d9 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.
Fixes: #17382
This reports uses of `File.exists?` and `Dir.exists?`, which were both
deprecated in Ruby and will eventually be removed in favor of
`.exist?`. Also fixes all existing uses of the deprecated methods.
Ci::Commit becomes a Pipeline object
1. Ci::Commit receives context: ref, :tag.
1. One Ci::Commit describes a one Pipeline
1. Pipeline is created from `.gitlab-ci.yml`
1. Pipeline is a ordered group of builds
1. We test MR against Pipeline
1. Pipelines have a separate view (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Pipeline can be triggered from UI (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Later we change `Trigger -> TriggerRequest -> Build` to `Trigger -> Pipeline` (future)
1. We add a Pipeline Hook that will be triggered on Pipeline status change (future)
1. We extend notifications to use `Pipeline Hook` to send summary on pipeline changes (future)
After merging that I'll prepare a separate MR that will unify naming, database columns, table names:
```
Ci::Commit -> Pipeline
Ci::Build -> Build
CommitStatus -> Job
GenericCommitStatus -> ExternalJob
ci_commits -> pipelines
ci_builds -> jobs
```
This MR implements first 5 points.
This is made to solve this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/14149.
See merge request !3653
Remove fork link closes all merge requests opened on source project
Currently, if you:
- create a fork
- open a merge request on the source project
- remove the fork link
The created MR cannot be closed.
With this MR, all pending MR is closed when the fork link is removed.
See merge request !3189
`MergeRequest#source_sha` is expected to return the sha of the source
branch last commit.
But when a open Merge Request has no diff (e.g. all commits have already
been merged to the target branch), `merge_request.source_sha`
incorrectly returns `nil`.
This was un-noticed before – but now that !2217 has been merged,
it makes `Gitlab::Git::Commit.between` raise an
"Unexpected nil argument" exception.
This fixes the crash, by making sure that `source_sha` returns a
correct result even when there is no diff available.
The OR condition for source_project_id/target_project_id leads to a
query plan that performs rather poorly on PostgreSQL due to the use of
sub-queries. Because Rails offers no easy alternative for this
particular problem we're forced to using a UNION for both conditions.
The resulting query performs much faster than just using an OR.
Indicate when an MR diverged from the target branch
This adds an indicator to the "Merge MR" box, to tell if and how much an MR diverged from its target branch.
For instance, consider an MR to merge the branch `feature` into `master`. Some other commits were added to `master` since `feature` was created, and the two branches diverged.
```text
o master
|
o o feature
| |
o o
| /
o
```
In this case, there will be a label in the MR Merge box stating:
> This MR is by 3 commits behind the target branch `master`.
## Screenshots
### The branch diverged from the target (UI Proposal)

### The branch diverged from the target (alternative UI Proposal)

## How is this useful?
- In a _rebase-workflow_ (MR are preferably rebased before being merged), the reviewer wants to know if an MR is rebased on the target branch before merging it.
_With this indicator, the reviewer knows immediately if the branch is rebased, or if she needs to ask the committer to rebase its branch._
<br>
- To keep the git history readable, a team prefers to avoid merging branches that really lag a lot behind the target branch. Merging an MR that is 10 commits behind is fine, but 200 is too much.
_With this indicator, the reviewer can see on the MR page if the branch is really far behind the target – or only a few commits behind._
## Open questions
We've been using this at @captaintrain for a few months now, and found it quite useful.
I guess the open-questions are mostly: what UI would be the more adequate? Any thoughts on this, on the general usefulness and/or on the code?
See merge request !2217
In case merge request is broken, we shouldn't check if the sha
is mergable, as it will be null, and there's no point, as we know
that it's not mergable.
Hide remove source branch button when new commit is added to branch
Fixes#3339
This MR hides the 'Remove source branch' button when a new commit is added to the source branch
/cc @DouweM
See merge request !2701
No space required after WIP identifier
Fixes#2426
Currently, the WIP: (or any other variation) prefix of a merge request title must include a trailing space for it to be recognized as a work in progress and prevent merging.
To resolve this, I added an or pattern to the regexp to look for any one of the three possible delimiters ':', ']', or ' '. This way the trailing space isn't required but it still won't mark any titles beginning with wip as work in progress (e.g. "Wipwap").
See merge request !1876
Instead of running ClosingIssueExtractor for every commit in a merge
request we can gather all the commit messages (and the merge request
description), concatenate all this together and then run
ClosingIssueExtractor only once.
The result of this is that MergeRequest#closes_issues is now between
3.5x and 4x faster than the old setup. Using a merge request with 10
commits (each referencing a number of issues to close) this reduced the
call duration from around 200 milliseconds to around 50 milliseconds.
As a result of these changes the Jira related tests for
MergeRequest#closes_issues have been removed. These tests stubbed
Commit#closes_issues meaning that the only code that was really tested
was the call to Array#uniq to filter out duplicate issues. As this code
is no longer used (nor present) the corresponding tests were removed.
Related: gitlab-org/gitlab-ce#12419