Create a todo on failing MR build
Implements #14067. I worked on this with @DouweM (any mistakes are mine).
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.
- I haven't tested this with a working CI setup, just with the unit tests below and by modifying my DB directly.
See merge request !3177
Resolve "Wrong sorting of commit order in MR view?"
!4052 fixed this for the most obvious cases, but there were still some problems.
Here's my test case: I have a branch where I was suffering from an unfortunate
issue. Every other commit I made had its commit date set to one day before it
should have been. (Perhaps my system clock was misbehaving.)
```shell
for i in {1..10}
do
echo $i > $i
git add $i
GIT_COMMITTER_DATE=`date -v -$((i % 2))d` git commit -m $i
done
```
The git CLI still gives me the commits in the right order, but I can see that
the timestamps alternate between two values:
```shell
$ git log --format='%h %ct %p %s' master...HEAD
f0c3108 1463646313 3d38a13 10
3d38a13 1463559913 67f419b 9
67f419b 1463646313 74330c0 8
74330c0 1463559913 56361d7 7
56361d7 1463646313 ba1b60c 6
ba1b60c 1463559913 f91497d 5
f91497d 1463646313 79c5e57 4
79c5e57 1463559913 b953cef 3
b953cef 1463646313 12fc411 2
12fc411 1463559913 835715b 1
```
Unfortunately, GitLab didn't like this _at all_. Here's what the commits on my
MR from that branch looked like:
That's because we were sorting the commits by date, which is safe if they are in
that order anyway. If they aren't, then because Ruby's sorting isn't stable, we
lose even the ordering among the correctly-ordered commits with the same
timestamp.
After these changes (and reloading the MR's diff), this looks like:
The commits view was also wrong, but in a slightly different way. In table form:
| View | Before | After |
| --- | --- | --- |
| Commit list | 10, 8, 6, 4, 2, 9, 7, 5, 3, 1 | 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 |
| MR commits | 10, 2, 8, 4, 6, 5, 7, 3, 9, 1 | 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 |
Closes#12724
See merge request !4208
fix#15127 ActiveJob::DeserializationError thrown
`send_devise_notification` pre-maturely enqueued the task when the user instance
has not yet been committed into the database, causing a record-not-found in the
other sidekiq process.
`devise-async` has already been taking care of asynchronous mail sending, we just
need to run it inside queue `mailers` instead of `mailer` to enable it.
The implementation of `devise-async` enqueues the task in `after_commit` hook
which is the right way to do it.
See merge request !3647
Add container registry support
Tasks:
- [x] Merge docker/distribution authentication service: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3787
- [x] Implement Docker Registry API
- [x] Show a list of docker images in GitLab
- [x] Remove registry repository on project deletion
- [x] Support project rename, move and namespace rename
- [x] Use token when connecting the registry
- [x] Allow to delete images from GitLab
- [x] Support pushing from GitLab CI (gitlab-ci-token / $CI_BUILD_TOKEN)
- [x] Support GitLab Runner pulling for public repositories
- [ ] Support GitLab Runner pulling for private repositories
- [x] Add tests for Docker Registry API
- [x] Add tests for a views
- [x] Make texts nicer
- [x] Implement a backup support
- [ ] Create administration documentation https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4141
- [ ] Create user documentation
See merge request !4040
`Gitlab::Git::Compare` will already have the correct order; sorting in
Ruby can only ruin that. (The correct order being the same as `git log`
- reverse chronological while maintaining the commit graph.)
As an example, imagine a branch where someone has their system clock set
wrong for some of the commits. Not only will those commits be in the
wrong order - which is maybe reasonable - but sorting in Ruby can also
put commits with the same timestamp out of order, as Ruby's sorting
isn't stable.
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.
Add an Event's target's title to its reference link
Given an activity feed entry like:
> Douwe Maan commented on [issue #123] at [gitlab-org/gitlab-ce]
...the `issue #123` link will now have a `title` attribute.
Plus some minor refactorings, see individual commits for details.
See merge request !4090
Given an activity feed entry like:
> Douwe Maan commented on [issue #123] at [gitlab-org/gitlab-ce]
...the `issue #123` link will now have a `title` attribute.
Make upcoming milestone work across projects
Before: we took the next milestone due across all projects in the
search and found issues whose milestone title matched that
one. Problems:
1. The milestone could be closed.
2. Different projects have milestones with different schedules.
3. Different projects have milestones with different titles.
4. Different projects can have milestones with different schedules, but
the _same_ title. That means we could show issues from a past
milestone, or one that's far in the future.
After: gather the ID of the next milestone on each project we're looking
at, and find issues with those milestone IDs. Problems:
1. For a lot of projects, this can return a lot of IDs.
2. The SQL query has to be different between Postgres and MySQL, because
MySQL is much more lenient with HAVING: as well as the columns
appearing in GROUP BY or in aggregate clauses, MySQL allows them to
appear in the SELECT list (un-aggregated).
Closes#17227.
See merge request !4125
Added authentication service for docker registry
This adds a simple authentication service for docker which uses current user credentials to authenticate pulls and pushes.
I have only one concern. Since the `.docker/config` is unencrypted, thus the password for user stored there is unencrypted, maybe we should from the start implement function to generate/provide a separate password just for the purposes of accessing docker registry?
What do you think @jacobvosmaer @sytses @marin?
cc @marin
See merge request !3787
Postgres only needs to select a single column, so that can used as a
sub-query where `Milestone.upcoming_ids_by_projects` is actually used in
`IssuableFinder`.
MySQL needs to select the `due_date` column because it's used in the
`HAVING` clause, so it has to return an array of IDs.
Before: we took the next milestone due across all projects in the
search and found issues whose milestone title matched that
one. Problems:
1. The milestone could be closed.
2. Different projects have milestones with different schedules.
3. Different projects have milestones with different titles.
4. Different projects can have milestones with different schedules, but
the _same_ title. That means we could show issues from a past
milestone, or one that's far in the future.
After: gather the ID of the next milestone on each project we're looking
at, and find issues with those milestone IDs. Problems:
1. For a lot of projects, this can return a lot of IDs.
2. The SQL query has to be different between Postgres and MySQL, because
MySQL is much more lenient with HAVING: as well as the columns
appearing in GROUP BY or in aggregate clauses, MySQL allows them to
appear in the SELECT list (un-aggregated).
James Lopez
Robert Speicher
Douwe Maan
Grzegorz Bizon
Rémy Coutable
Stan Hu
Rubén Dávila
Kamil Trzciński
Sean McGivern
Jeroen van Baarsen
Sean McGivernandSean McGivern
Felipe Artur
Robert Speicher
Douwe Maan