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
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).
Improve documentation and web test for web hooks
Tips and documentation of actual hook behavior. Improved user feedback
when testing hooks via the web UI.
See merge request !4015
`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:
1. It assumes a user can always view all of their starred projects in
perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
can view. This is currently the case, but bugs happen.
Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.
Revert "Merge branch 'wiki-fix' into 'master'"
This reverts commit 4cc85a58e8 (!4026), reversing
changes made to 90ae445ba9.
From https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4026#note_11719950:
> 1. On Ruby 2.1.x, the [`uri.path = ::File.join(project_wiki_base_path, uri.path)`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/banzai/filter/wiki_link_filter.rb#L39) raises an `URI::InvalidComponentError: bad component(expected relative path component): http://bar.com/baz` error in `Banzai::Filter::WikiLinkFilter#rebuild_wiki_uri`, which is then rescued in [`Banzai::Filter::WikiLinkFilter#process_link_attr`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/banzai/filter/wiki_link_filter.rb#L34), thus the link is not modified and the tests pass.
1. On Ruby 2.2.x, the same line doesn't raise an error anymore, thus tests are broken on Ruby 2.2 only. I didn't really understand yet why having absolute links in the wiki would break some tests vs having relative links as before, but I think the safest course to action is to revert this MR and to find another fix (probably just prepending `ProjectWiki#wiki_base_path` with the relative URL path component if we are in the case of a relative URL...
/cc @artem-sidorenko
Just a FYI note: no need to pick into `8-7-stable` since the original commit was not picked.
See merge request !4105
Remove the annotate gem and delete old annotations
In 8278b763d9 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
/cc @yorickpeterse
See merge request !4099
In 8278b763d9 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
Use the proper GitLab URL for links in Wiki
Fixes gitlab-org/gitlab-ce#17071
wiki links are proper compiled, e.g.
```
[same-level](same-level) -> <a href="same-level">same-level</a>
[sub-level](sub/level) -> <a href="sub/level">sub-level</a>
[upper-level](../upper-level) -> <a href="../upper-level">upper-level</a>
```
See merge request !4026
Use Rugged's TagCollection#create instead of gitlab-shell's Repository#add_tag for better performance
This was originally opened at !1757 by @pcarranza but I changed it to use Rugged instead of gitlab_git, following @DouweM's request.
Once this is merged, https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/26 will be mergeable too.
See merge request !3745
This changes Project#protected_branch? to use a query to check if a
branch is protected, instead of loading all ProtectedBranch records into
memory just to check if the list of names includes a given branch name.
This is a combination of 3 commits.
- Update the bare repositories info/attributes if the default branch is updated
- Check the diff attributes of a file before showing a diff
- Update CHANGELOG
Ci::Commit becomes a Pipeline object
1. Ci::Commit receives context: ref, :tag.
1. One Ci::Commit describes a one Pipeline
1. Pipeline is created from `.gitlab-ci.yml`
1. Pipeline is a ordered group of builds
1. We test MR against Pipeline
1. Pipelines have a separate view (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Pipeline can be triggered from UI (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Later we change `Trigger -> TriggerRequest -> Build` to `Trigger -> Pipeline` (future)
1. We add a Pipeline Hook that will be triggered on Pipeline status change (future)
1. We extend notifications to use `Pipeline Hook` to send summary on pipeline changes (future)
After merging that I'll prepare a separate MR that will unify naming, database columns, table names:
```
Ci::Commit -> Pipeline
Ci::Build -> Build
CommitStatus -> Job
GenericCommitStatus -> ExternalJob
ci_commits -> pipelines
ci_builds -> jobs
```
This MR implements first 5 points.
This is made to solve this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/14149.
See merge request !3653
Douwe Maan
Rémy Coutable
Felipe Artur
Douwe Maan
Sean McGivern
Douglas Barbosa Alexandre
Artem Sidorenko
Gabriel Mazetto
Ahmad Sherif
Andrei Gliga
Robert Speicher
Yorick Peterse
Jeroen van Baarsen
Jacob Vosmaer
Robert Speicher
Matt Oakes
Paco Guzman
Grzegorz Bizon
Connor Shea
Stan Hu
James Lopez
Kamil Trzciński