API: List issues for a particular milestone
# What does this MR do?
This MR adds a new API method for retrieving the issues associated with a particular milestone. The resource is described at ":id/milestones/:milestone_id/issues", returning a simple array of issues.
I've picked up gitlab-org/gitlab-ce!113 and fixed the test for it.
From the original MR:
This feature was motivated by an in-house project for reporting--for large projects, retrieving and filtering the entire issue list by milestone was becoming too slow, particularly when pagination required multiple requests. While this resource also uses pagination, it allows the consumer to limit reporting to the particular milestone they are interested in.
@dblessing Please take a look :)
See merge request !308
print validation errors when gitlab-rake gitlab:import:repos fails for project
Currently, when gitlab-rake gitlab:import:repos is not able to import a project it justs prints "Failed trying to create project" to the console. There seems to be no way to find out what exactly has failed. Since the check uses validation, it should at least print the validation issues. That might be a bit cryptic, but may be better than leaving the user in the dark completely.
See merge request !147
Check for database connection when running current_application_settings
The PG connection errors don't always end up being caught as ActiveRecord::NoDatabaseError. So when doing a precompile without the database (like when using the omnibus), an exception was being thrown.
See merge request !292
I decided to create a fork of rouge as rouge lacks a HTML formatter with
the required options such as wrapping a line with <span> tags.
Furthermore I was not really convinced about the clarity of rouge's
source code.
Rugments 1.0.0beta3 for now only includes some basic linting and a new
HTML formatter. Everything else should behave the same.
While loading the Rails app we cannot assume that the gitlabhq_xxx
database exists already. If we do, `rake gitlab:setup` breaks!
This is a quick hack to make sure that fresh development setups of
GitLab (from master) will work again.
On some misconfigured GitLab servers, if you look in production.log it looks
like all requests come from 127.0.0.1. To avoid unwanted banning we
white-list 127.0.0.1 with this commit.
Dmitriy Zaporozhets
Mika MäenpääandHannes Rosenögger
Jacob Vosmaer
Hannes Rosenögger
Justin WhearandHannes Rosenögger
Valery Sizov
jubianchi
Marin Jankovski
Jeroen van Baarsen
Daniel Serodio
Stefan Tatschner
Sytse Sijbrandij
DJ Mountney
Marin Jankovski
Jacob Vosmaer
Dmitriy Zaporozhets
Valery SizovandValery Sizov
mattes
Stephan van Leeuwen