Instrument all Grape API helpers
This has been added to help us figure out what's making certain Grape API calls slow (e.g. the one used for authorized keys as described in gitlab-com/operations#99).
See merge request !4169
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
Disallow search engines from indexing uploads from a GitLab project.
This can sometimes include sensitive information from private projects and confidential issues. It shouldn't be indexed. Resolves#15551.
cc: @DouweM
See merge request !4167
Add tests for unintentional filtering bug in MR
!3872 has a lack of tests for Merge Requests while !3872 has only ones for Issues.
This MR has complementary tests for MR list.
See merge request !4154
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).
Phil Hughes
Rémy Coutable
Felipe Artur
Robert Speicher
James Lopez
Yorick Peterse
Dmitriy Zaporozhets
Douwe Maan
Connor Shea
Robert Speicher
Douwe Maan
Kamil Trzcinski
Sean McGivern
Pablo Carranza
Takuya Noguchi