This commit enables the usage of the Gitlab Markdown post processing
on all Markdown formatted files. For file types that do not contain
Markdown, it defaults to the Gollum native renderer to process the
content.
This commit adds a new Rake task for migrating all of your existing
Wiki content from your database into new Gollum repositories.
The bulk of the logic happens within the `WikiToGollumMigrator`
class which is decently test covered and located in the lib directory.
The new Rake task can be executed by running:
`bundle exec rake gitlab:wiki:migrate`
It will output a nice log of every project that it migrates along
with success or failure messages.
I have used it on my own installation to migrate my Wikis successfully.
This commit replaces the old database backed Wiki system with the
excellent Gollum git based Wiki system.
The UI has been updated to allow for utilizing the extra features
that Gollum provides. Specifically:
* Edit page now allows you to choose the content format.
* Edit page allows you to provide a commit message for the change.
* History page now shows Format, Commit Message, and Commit Hash.
* A new Git Access page has been added with the Wiki Repo URL.
* The default page has been changed to Home from Index to match
the Gollum standard.
The old Wiki model has been left in tact to provide for the
development of a migration script that will move all content stored
in the old Wiki system into new Gollum Wikis.
Added a helper method to check if required parameters are given in an API call. Can be used
to return a `400 Bad Request` return code if a required attribute is missing.
Code clean up and fixed tests.
The API documentation of merge requests contains info to status codes for all functions.
Required arguments are now checked in the merge requests API functions and a `400 Bad Request` error is
returned if they are not given.
The issues documentation is updated with infos to status codes and the deprecated `DELETE` function and
how to close an issue. A few more tests added to check status codes of API functions.
Updates the API documentation of groups with infos to return codes. The function calls
in the groups API have updated documentation and return `400 Bad Request` status code
if a required attribute is missing.
The API documentation of repository is updated and now contains infos to status codes.
Code documentation is also adjusted for `GET /projects/:id/repository/commits` and includes infos to
pagination attributes. Tests are updated.
The notes API documentation updated with return codes. API now returns `400 Bad Request` if
required attributes are not present. Return codes are documented now, also tested in added tests.
The documentation now reflects the current state of the API.
The users API updated with return codes, e.g. if required parameters are missing
a `400 Bad Request` error is returned instead of `404`. Fixes return codes of functions,
e.g. deletion of a ssh key is an idempotent function now.
The API documentation is updated to reflect the current status of the API. Descriptions
are more detailed and complete, infos to return values are added to all functions.
When a user is not authorized to see the list of hooks for a project, he is
still able to access the hooks separately. For example if access to
`GET /projects/:id/hooks` fails and returns a `403 Unauthorized` error it is
still possible to access a hook directly via `GET /projects/:id/hooks/:hook_id`.
Fixes access, also added tests to check access and status codes of hooks.
When the project limit is reached the user is not allowed to create new ones.
Instead of error code 404 the status code 403 (Forbidden) is returned with error
message via API.
When reaching the project limit the API returns an error code 404 on the last possible
project. The project itself is created and is available in the database (seems valid).
A similar behavior can be observed when reaching the project limit via web client, but
in this case the user is notified that the maximum number of projects is reached. The project
itself is still created and can be accessed.
Tests are added to check the behavior when reaching the project limit or one tries
to exceed it via the API.
Extracted a method for 400 error (Bad request) and adjusted code accordingly. The name of
the missing attribute is used to show which one was missing from the request. It is used to
give an appropriate message in the json response.
When using project snippets via API the functions now provide status codes for
different situations other then only returning 404 error. If required parameters are missing,
e.g. `title` when creating a project snippet a 400 (Bad request) error is returned. The snippet
delete function now is idempotent and returns a 200 (Ok) regardless if the snippet with the
given id is available or not. Changing return codes of these functions has the advantage that
the 404 error is used only for resources, which are not available.
Tests added to check these status codes when handling project snippets.
