These three tests were essentially checking that adding a note to
something updated its `noteable`'s `updated_at` attribute.
This is well-tested Rails behavior and we shouldn't feel the need to
write an integration test to verify it. At most we should be ensuring
that the association definition adds the `touch: true` option, which we
now do in Note's unit test.
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
workaround for forks with an invalid repo
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/13465
The error occurs when a project returns a `nil` commit for a variety of reasons, I assume the repository is corrupt - perhaps as a result of a failed fork.
With this MR, we do not show forks with corrupted repos in the list of forks, as this does not seem to work anyway. A better solution is to fix the cause of the issue and/or any data integrity problem...
Also fixing Sentry issue: 1180
`undefined method 'already_forked?' for nil:NilClass `
See merge request !2836
1. We now display the index of the current issuable among all its project's
issuables, of the same type and with the same state.
2. Also, refactored a bit the Issuable helpers into a new IssuablesHelper
module.
3. Added acceptance specs for the sidebar counter.
Add tests for clicking a row in build artifacts browser
This adds a feature tests for clicking a row, which is handled by javascript event.
/cc @ayufan
See merge request !2551
This commits also fixes two minor issues:
- Ensure notes that the current user is not allowed to see are not
returned in the AJAX notes loading
- Ensure the notes counter badge is decremented of 1 instead of 2
Robert Speicher
Douwe Maan
Grzegorz Bizon
Pierre de La Morinerie
Dmitriy Zaporozhets
Phil Hughes
Rémy Coutable
Rubén Dávila
Jacob Schatz
Grzegorz BizonandGrzegorz Bizon
James Lopez
Douglas Barbosa Alexandre
Stan Hu
Kamil Trzcinski