Block the reported user before destroying the record
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
See merge request !2402
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
Improve performance of getting issues on group level
For testing I used the URL http://localhost:3000/groups/gitlab-org/issues?milestone_title=8.1. Prior to these changes said URL would take about 10-12 seconds to load. By applying these changes the loading time has been reduced to roughly 2-3 seconds.
There's still some stuff going on in some views that I have to look at, resolving those changes might reduce the loading time a bit more. I also still have to check if I didn't break too many tests.
Fixes: gitlab-org/gitlab-ce#3707 gitlab-org/gitlab-ce#4071
See merge request !2318
Do not call API if there is no API URL
Fixes#5878
CE users may not be interested in the new JIRA features. In this case,
we should detect they haven't set an API URL and fallback to the
behavior pre-8.3. This patch does that very easily.
There are planned improvements to JIRA in future releases such as
gitlab-org/gitlab-ce#5541 which will make this more configurable.
See merge request !2341
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
Project services and JIRA documentation clean up
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/176
This was first aiming to fix the JIRA references to EE, but as I was going through it, I decided to revamp more.
@Haydn once merged here and then Valery merges CE into EE it should be fixed in doc.gitlab.com as well.
@dblessing the docs state that we support JIRA 6.x. I see that 7.x is out, should the docs be amended? Also we seem to have a place to document services (http://doc.gitlab.com/ce/project_services/project_services.html), but the JIRA doc is under integration :/ I'd like it to have it moved under `project_services/`, but I guess most customers know the current URL better.
See merge request !2345
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`.
This replaces plucking of IDs with a sub-query, saving the overhead of
loading the data in Ruby and then mapping the rows to an Array of IDs.
This also scales much better when dealing with a large amount of IDs
that would be involved.
Sorting by "id" has the same effect as sorting by created_at while
performing far better and without the need of an extra index (in case
one wanted to speed up sorting by "created_at").
Sorting by "Recently updated" still uses the physical "updated_at"
column as there's no way to use the "id" column for this instead.
Get "Merge when build succeeds" to work when commits were pushed to MR
target branch while builds were running
The Merge when build succeeds service only merges when the MR is
mergeable (open, not WIP, no conflicts).
When the target branch is updated, all affected MRs have their merge
status set to `unchecked`, and the conflicts check will only happen
when `check_if_can_be_merged` is called, which happens when the MR page
is viewed.
When someone enables the automatic merge, the target branch is updated,
no-one views the MR page again, and the build succeeds, the mergeability
check will fail and the MR will not in fact be merged.
This MR makes sure `check_if_can_be_merged` is always called when MR
mergeability is checked.
See merge request !2304
Validate README format
Take the first previewable README file as project's README, otherwise if
none file is available, or we can't preview any of them, we assume that
project doesn't have a README file.
Fixes#3978
Take the first previewable README file as project’s README, otherwise
if none file is available, or we can’t preview any of them, we assume
that project doesn’t have a README file.
Added system hooks messages for renaming and transferring a project
This is work in progress but I wanted to get some feedback on it in case there is something I've missed or a better way to do it.
As the title says when a project is renamed or transferred to another group a system hook message is generated.
Currently adds a couple of extra properties to the standard project system hooks messages.
old_path_with_namespace - The old path of the project so we can see what has been renamed / transferred
changed_at - The time that change took place
My main concern is if there is a better way of doing this than passing the extra_data variable into the system hook. Would it be better to extend the project model with these 2 items as transient properties as I doubt they would need to be saved to the database? The other
I've also seen, but can't find, someone talking about the emails sent when a project is renamed or transferred doesn't reference the original project path so if you have similarly named projects then you might not know what has been moved. I think the extra_data (or however it is best to implement this) would allow the extra information to be sent in emails.
Closes [System hooks for project transfer and repository rename](http://feedback.gitlab.com/forums/176466-general/suggestions/6006233-system-hooks-for-project-transfer-and-repository-r)
See merge request !611