This is a draft implementation of HTTP adapters solving #49.

The library now supports:

• Guzzle 3
• Guzzle 4
• Buzz

The user has to choose an adapter when creating the API client :

<?php

$buzz = new \Gitlab\HttpClient\Adapter\BuzzAdapter();
$guzzle3 = new \Gitlab\HttpClient\Adapter\Guzzle3Adapter();
$guzzle4 = new \Gitlab\HttpClient\Adapter\Guzzle4Adapter();

$bgitlab = new \Gitlab\Client('http://git.foobar.com/api/v3/', $buzz);
$bgitlab->authenticate('foobar', \Gitlab\HttpClient\HttpClientInterface::AUTH_HTTP_TOKEN);

$g3gitlab = new \Gitlab\Client('http://git.foobar.com/api/v3/', $guzzle3);
$g3gitlab->authenticate('foobar', \Gitlab\HttpClient\HttpClientInterface::AUTH_HTTP_TOKEN);

$g4gitlab = new \Gitlab\Client('http://git.foobar.com/api/v3/', $guzzle4);
$g4gitlab->authenticate('foobar', \Gitlab\HttpClient\HttpClientInterface::AUTH_HTTP_TOKEN);

:warning: This will break user's code when updating the library :warning: but I think it's a minor change.

The Gitlab\HttpClient\Listener\ErrorListener will produce a Fatal error (Wrong parameters for ErrorException) when the Gitlab API returns a error message that contains an array instead of a string message. Offending line: 46

{"message":{"path":["has already been taken"]}}

This will mostly happen when an data validation error occurs. See Data validation and error reporting for possible response formats.

A simple solution could be to json encode the message when it's not a string.

Used versions: GitLab 7.4.0; GitLab API v3

As discussed in #171 this replace the buzz client by httplug.

I tried to implement this as it was done by @Nyholm for https://github.com/KnpLabs/php-github-api. This remove all the HttpClient stuff which was built on the top of Buzz. Instead it use Httplug standard plugins with a few custom ones for error handling and authentication.

I set PHP required version to 5.6+ as discussed in #171.

This IS a breaking change.

To do

• [x] Update documentation.
• [x] Describe breaking changes.
• [x] Add tests.
• [x] Do intensive tests against real gitlab repositories.
• [x] Update ResultPager.
• [x] https://github.com/m4tthumphrey/php-gitlab-api/pull/191#issuecomment-308155979

I added the create/edit/delete Endpoints described in https://docs.gitlab.com/ee/api/pipeline_schedules.html#create-a-new-pipeline-schedule-variable.

Closes #508.

https://about.gitlab.com/2017/02/22/gitlab-8-17-released/ With v4 in beta and set to be released on 3/22 is their any current plans on how to update this project to use the new api?

Getting error: {"error":"file_path is missing, branch_name is missing, commit_message is missing, content is missing"}

I am using syntax $project->createFile('file1', 'contents', 'master', 'file');

So far I have $project->getFile() working so I am not sure if this is a bug or like a permissions problem?

I am trying to create issues, but its not possible.

Using this code: $client->api('issues')->create(220, ['title' => 'Test', 'description' => 'test']);

If I var_dump the $params in AbstractApi post method i do get a return like this:

array:2 [
  "title" => "Test"
  "description" => "test"
]

But still i get the response: Gitlab\Exception\ErrorException with message '400 (Bad request) "title" not given'

The GitLab API normally limits the list of issues to 100 entries per request, with a default of 20. This means that Issues::all() and Project::issues() by extension only return the first 20 issues of a project by default, which is surprising given their respective names. It'd be nice if the docs stated this fact, and provided a workaround.

I'd be willing to write a PR for this.

the server's answer for blocking a user is a bool value but the API expects an array which lead to an exception

$gitlab = new Gitlab\Client();
$gitlab->setUrl('customgitlaburl');
$gitlab->authenticate($gitlab_api_access_token, Gitlab\Client::AUTH_HTTP_TOKEN);
$user = $gitlab->users()->all(array("username" => $username));
$gitlab->users()->block($user[0]["id"]);

Result: PHP Fatal error: Uncaught Gitlab\Exception\RuntimeException: json_decode error: Expected JSON of type array, bool given. in /home/gitlab_ad_usersync/include/gitlab_api/vendor/m4tthumphrey/php-gitlab-api/src/HttpClient/Util/JsonArray.php:33 Stack trace: #0 /home/gitlab_ad_usersync/include/gitlab_api/vendor/m4tthumphrey/php-gitlab-api/src/HttpClient/Message/ResponseMediator.php(49): Gitlab\HttpClient\Util\JsonArray::decode('true') #1 /home/gitlab_ad_usersync/include/gitlab_api/vendor/m4tthumphrey/php-gitlab-api/src/Api/AbstractApi.php(143): Gitlab\HttpClient\Message\ResponseMediator::getContent(Object(GuzzleHttp\Psr7\Response)) #2 /home/gitlab_ad_usersync/include/gitlab_api/vendor/m4tthumphrey/php-gitlab-api/src/Api/Users.php(200): Gitlab\Api\AbstractApi->post('users/78/block') #3 /home. in /home/gitlab_ad_usersync/include/gitlab_api/vendor/m4tthumphrey/php-gitlab-api/src/HttpClient/Util/JsonArray.php on line 33

same for the unblock method. blocking and unblocking is executed nonetheless

GitLab API per default defines 20 items per_page for the returned result. Now if a project has more than 20 members we have an issue with increasing the number of items to max i.e. 100.

Therefore I complemented your code.

Many thanks!

It's hard to keep up-dated. Unless someone wants to volunteer to spend a lot of time going through all of the models code updating it, maybe we should remove the models entirely?

The Gitlab-Api (https://docs.gitlab.com/15.4/ee/api/pipelines.html#list-project-pipelines) states that pipelines can be ordered by 'updated_at' as well. It already works by allowing it here.