| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When a build fails for a commit, create a todo for the author of the
merge request that commit is the HEAD of. If the commit isn't the HEAD
commit of any MR, don't do anything. If there already is a todo for that
user and MR, don't do anything.
Current limitations:
- This isn't configurable by project.
- The author of a merge request might not be the person who pushed the
breaking commit.
|
|
|
|
In 8278b763d96ef10c6494409b18b7eb541463af29 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
|
|
Backport changes from gitlab-org/gitlab-ee!372
Mostly replaces several Spinach tests with RSpec Feature tests.
See merge request !4043
|
|
|
|
Mostly replaces several Spinach tests with RSpec Feature tests.
|
|
|
|
|
|
Fix revoking of authorized OAuth applications
Users were not able to revoke access to authorized OAuth applications. Clicking the "Revoke" button would result in a 404 page, and the application would still be authorized.
Added a spec and also found that the `gon` variables were not being set for this view.
Closes #14370
See merge request !3690
|
|
|
|
Closes #14370
Move gon function into its own helper
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
This fixes ./spec/services/projects/unlink_fork_service_spec.rb which
somehow started failing on the master branch. It certainly isn't a very
elegant solution but seems to be the easiest/best way of solving this
problem for the time being.
|
|
|
|
This attempts to get CarrierWave's uploader - `FileUploader` into test
harness using a factory. that makes it easier to build an instance of
it.
Along with !3435 it may be easier to use uploaders in tests
|
|
|
|
|
|
|
|
|
|
|
|
Fix MergeRequest#source_sha when there is no diff
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/14170
### Overview
This MR fixes an unhandled Exception when visiting the page of an open Merge Request without diff.
### Description
`MergeRequest#source_sha` is expected to return the sha of the source branch last commit. But when an 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 without consequences before – but since !2217 was merged (a few days ago), it makes `Gitlab::Git::Commit.between` raise an "Unexpected nil argument" exception. This can be reproduced when visiting the http://localhost:3000/gitlab-org/gitlab-test/merge_requests/2 page on a fresh local Gitlab setup.
This MR fixes the crash, by making sure that `source_sha` returns a
correct result even when there is no diff available. I also added tests.
@DouweM I believe you wrote most of this code in the first place ; does this looks correct to you, or is there a better way to resolve this issue maybe?
See merge request !3135
|
|
|
|
`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.
|
|
1. Make the "subscribed" text in Issuable sidebar reflect the labels
subscription status
2. Current user mut be logged-in to toggle issue/MR/label subscription
|
|
1. Allow subscribing (the current user) to a label
- Refactor the `Subscription` coffeescript class
- The main change is that it accepts a container, and conducts all
DOM queries within its scope. We need this because the labels
page has multiple instances of `Subscription` on the same page.
2. Creating an issue or MR with labels notifies users subscribed to those labels
- Label `has_many` subscribers through subscriptions.
3. Adding a label to an issue or MR notifies users subscribed to those labels
- This only applies to subscribers of the label that has just been
added, not all labels for the issue.
|
|
Revert the avatar cropping feature
Reverts !2951 since the added 'mini_magick' dependency should be replaced by client-side croppping
See merge request !3223
|
|
Fixes "iid of max iid" in Issuable sidebar for merged MR
Fixes #13928.
See merge request !3046
|
|
This reverts commit 01160fc06182de89c400af174861f6545ad6ceb8, reversing
changes made to 4bff9daf8b6d85e9c78565e21cfaa3f6d36f0282.
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
Fixes #13928
|
|
More Factory cleanup
Addresses nitpicks from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2847
See merge request !3108
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
The only major difference with the EE version is the change from a light and dark logo to only a header logo
The dark logo wasn't used anyway, so it seemed to make sense to me to rename the field to the actual function of it
|
|
|
|
|
