The API documentation for projects now is structured into major sections that describe
the different aspects when dealing with projects, e.g. hooks, branches, team members etc.
All described methods now contain a list of possible status codes the method can return. A few
methods have extra sample JSON responses and a description if a method is idempotent.
Idempotent methods can be called multiple times while returning the same status code.
This option allows to disable users from changing their username.
This is very usefull in environments using strong internal authentication methods like ldap, pam or shibboleth.
You can allow users to change theyr username in these environments, but then new users (users loging in first time) is blocked from gitlab is her username exists.
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.
The previous call `saved?` is restored in the `POST /projects` method in the API.
It is refactored to check if the record is persisted. This is useful to not validate
the record again after saving. This fixes the returned status code in the web client
too. If the last project is created via web client instead of error notification
the project page is shown.
When creating the last project via API when reaching the project limit a status code
of 404 (Not found) is returned instead of 201 (Created). The fix checks now correctly if
the project could be saved.
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.
Different status codes in the API lib are returned on hook creation, update or deletion.
If a required parameter is not given (e.g. `url` in `/projects/:id/hooks/:hook_id`) status
code 400 (Bad request) is returned. On hook deletion a 200 status code is returned, regardless if
the hook is present or not. This makes the DELETE function an idempotent operation. Appropriate tests
are added to check these status codes.
Mac OS uses launchd instead of /etc/init.d to start daemons and tasks to be started by launchd MUST NOT daemon itself. So "nohup" here won't work for Mac OS.
Can we add a "launchd" task to the rake file so that we can start sidekiq as "bundle exec rake sidekiq:launchd" ?
