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
fix syntax error on 2.1 and rubocop on 2.2
Background:
Hashes `{:'key': 'value'}` are not valid in 2.1 but are recommended by Rubocop on 2.2. We only use those when we have a key such as `weird-key`, `weird.key`, etc...
We could disable Rubocop but it wouldn't warn us about the recommended syntax since `Ruby 1.9`: `{key: 'value'}`, which is valid for `Ruby 1.9+`.
Workaround 1 could be disabling `Style/HashSyntax:` in `rubocop.yml`.
Workaround 2 (tried in this MR) is to trick Rubocop using `.to_sym` which is effectively the same as adding the `:`. This would allow to keep the warning in place.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/12801
See merge request !2637
By simply loading the first event from the already sorted set we save
ourselves extra (slow) queries just to get the latest update timestamp.
This removes the need for Event.latest_update_time and significantly
reduces the time needed to build an Atom feed.
Fixesgitlab-org/gitlab-ce#12415
The pattern in the `::reference_pattern` class method in the
ExternalIssue model does not match all valid forms of JIRA project
names. I have updated the regex to match JIRA project names with numbers
and underscores. More information on valid JIRA project names can be
found here:
https://confluence.atlassian.com/jira/changing-the-project-key-format-192534.html
* The first character must be a letter,
* All letters used in the project key must be from the Modern Roman Alphabet and upper case, and
* Only letters, numbers or the underscore character can be used.
LDAP Sync blocked user edgecases
Allow GitLab admins to block otherwise valid GitLab LDAP users
(https://gitlab.com/gitlab-org/gitlab-ce/issues/3462)
Based on the discussion on the original issue, we are going to differentiate "normal" block operations to the ldap automatic ones in order to make some decisions when its one or the other.
Expected behavior:
- [x] "ldap_blocked" users respond to both `blocked?` and `ldap_blocked?`
- [x] "ldap_blocked" users can't be unblocked by the Admin UI
- [x] "ldap_blocked" users can't be unblocked by the API
- [x] Block operations that are originated from LDAP synchronization will flag user as "ldap_blocked"
- [x] Only "ldap_blocked" users will be automatically unblocked by LDAP synchronization
- [x] When LDAP identity is removed, we should convert `ldap_blocked` into `blocked`
Mockup for the Admin UI with both "ldap_blocked" and normal "blocked" users:
There will be another MR for the EE version.
See merge request !2242
Show referenced MRs & Issues only when the current viewer can access them
This addresses both issues identified in #6066.
## The private MR by user `remy2` with a note referencing to a public issue
---
## The public issue viewed by user `remy` **who doesn't have access to `remy2/private-project`** before the fix
---
## The public issue viewed by user `remy` **who doesn't have access to `remy2/private-project`** with the fix
---
## The public issue viewed by user `remy2` with the fix (no change)
See merge request !2405
This is intended to prevent the user from creating new objects while the
transaction that removes them is being run, resulting in objects with
nil authors which can then not be edited.
See https://gitlab.com/gitlab-org/gitlab-ce/issues/7117
Suppress e-mails on failed builds if allow_failure is set
Every time I push to GitLab, I get > 2 emails saying a spec failed when I don't care about the benchmarks and others that have `allow_failure` set to `true`.
@ayufan mentioned creating a summary e-mail to prevent getting one e-mail per build, but the latter might actually be desirable. For example, I do want to know if Rubocop errors fail right away.
See merge request !2178
Every time I push to GitLab, I get > 2 emails saying a spec failed when
I don't care about benchmarks and other specs that have `allow_failure` set to `true`.
Robert Speicher
Yorick Peterse
Dmitriy Zaporozhets
Douglas Barbosa Alexandre
Josh Frye
Marin Jankovski
Douwe Maan
James Lopez
Douwe Maan
Robert Speicher
Blake Hitchcock
Kamil Trzcinski
Jeroen Nijhof
Grzegorz Bizon
Rémy Coutable
Gabriel Mazetto
Stan Hu