I've needed to pull in 3rd party libraries as well so I don't have to manually list them in all of the composer.json files for different projects. I can change the static-repos.json sample to a different project if you want me to, just let me know.

Hello,

I switched to Repository::getFile() because Repository::blob() returns the base64 string with a prefix which I did not want to take care of. This should solve issue #24 Best, Ramon

Hi,

Great job with this script.

It's no bug merely a suggestion for improvement. I don't even now if it's possible with the Gitlab API but it could be nice to add a dist node in the packages.json that point to the zip download URL in Gitlab to improve downloading through composer.

David

Under my gitlab install, $repos->blob(..) returns an array, not a string as expected. As I'm not sure if this is the same behaviour across the board added ternary statement to catch this.

First of all, I really like this project. :)

I'm having one issue though: with the current code, the group/project must match vendor/package, otherwise libraries are not added to the generated package list.

Since I have to deal with a bunch of packages who's vendor name is not a 1:1 match with the group name in GitLab, that means I cannot use this project as-is. I've got a rough implementation ready that does work, by using the name from composer.json in the default_branch as package name, My current implementation is not optimal ($fetch_ref is executed twice for the default_branch of every project) yet, but I wanted to ensure it worked first.

If you guys are interested, I can whip up a PR with my changes (after getting rid of that double $fetch_ref call, obviously) - while most people probably won't have this problem, composer doesn't require that group/project is alwasy the same as vendor/package, so supporting such a setup doesn't sound like a terrible idea.

Currently .htaccess contains:

Satisfy any
Allow from all

I think there is no need for that directives and in some cases can cause unexpected security issues

Problem: Uncaught TypeError: Argument 1 passed to Gitlab\Client::__construct() must be an instance of Gitlab\HttpClient\Builder, string given around line 40 of packages.php.

Solution:

1. composer require php-http/curl-client guzzlehttp/psr7 php-http/message
2. change $client = new Client($confs['endpoint']); to $client = Client::create($confs['endpoint']);
3. Around line 184, always call ->all instead of ->accessible, as the method has been removed.

Update m4tthumphrey/php-gitlab-api to Version 9.0 with Guzzle 6 HTTP adapter. Change packages.php adapted to https://github.com/m4tthumphrey/php-gitlab-api/blob/9.0.0/UPGRADE.md

Hello, we are using gitlab in version 8.15.4 and Repository::blob api call returns an base64 encoded string instead of the file content. So building package.json is not longer working. I hope I did not overlook something obvious.

Best, Ramon

It seems the call to projects->all needs admin privileges. It should be possible to user the projects->accessible api in case of an unprivileged user account.

https://github.com/wemakecustom/gitlab-composer/blob/master/htdocs/packages.php#L82

-        return array();
+        $version = 'dev-'.$ref['name'];

This did the trick for us.

Webhooks

This is feature allows to get immediately updates to the composer registry if a new version (tag) was released. It comes with a lot of new security settings e.g. a webhook token can be defined, that is used to authenticate requests from gitlab, and a webhook url that is used to define the self url in a secure way. also some ip settings to restrict access to certain ips. Performance of webhooks is good, because they write directly in the cache files and by that they are avoiding the cache to become stale.

You may wonder about huge refactoring

Refactoring was made to make the script make object oriented with the idea of being able to reuse things easier and to separate things into different files. There is room for improvements because not everything was refactored yet. BTW the old code had it's beauty, anyway when continuing adding features it will hopefully be a benefit to move into this object oriented direction.

Outlook

The webhooks can be used to preserve the cache for a long time, but there is a known limitation: deleting a version/tag is not covered by the current logic (because it is not my major use case) and should be implemented in future to make things feature complete. Based on the refactoring maybe someone will add more features. The new authentication layer would allow to add new features e. G. a gitlab token based authenticate as alternative or addition to the IP based authentication.

It'd be really nice to allow requests coming from gitlab webhooks update projects, or better yet just that one project associated with the webhook, so we don't have to wait for cron.

It looks very easy to trigger update from webhook, but given the architecture, it looks a bit challenging to only update a given repository without checking all others. Any interest in this? It'd require a pretty decent refactor.

Since version 8.7.1 Gitlab updates project.last_activity_at not more often than once in a minute. This leads to the problem, when project.last_activity_at < last commit datetime, and therefore to not updating the packages.json. @see: https://gitlab.com/gitlab-org/gitlab-ce/issues/22213

With GitLab CE Merge Request !6391 the last_activity_at column is restricted to one update per hour.

Since the packages.php script relies on the last_activity_at value to determine if the packages.json needs to be updated in general and which project in perticular, you may now get an "outdated" packages.json if you push frequently.

I'm not sure how packagist internally works, but an example can be seen here:

https://packagist.org/p/laravel/framework.json https://packagist.org/packages/laravel/framework https://github.com/laravel/framework/branches

As you can see there is a "5.0.x-dev" that refers to the "5.0" branch on github.

Based on what is written here: https://getcomposer.org/doc/02-libraries.md#branches

I would suggest that any branch that looks like a version, should be listed as 5.0.x-dev

would be really awesome to change the code to allow access multiple gitlab instances.

IMHO there are several steps to take:

• convert settings file form ini to yaml
• iterate over instances and then repos to get the needed information
• put all the stuff into one file

The yaml file may look like:

m4tthumphrey:
  php-gitlab-api:
    instances:
      -
        apiToken: 'ASDFGHJKL12345678'
        endpointUri: 'http://gitlab.example.com/api/v3/'
      -
        apiToken: 'ASDFGHJKL12345678'
        endpointUri: 'http://gitlab.example.com/api/v3/'
      -
        apiToken: 'ASDFGHJKL12345678'
        endpointUri: 'http://gitlab.example.com/api/v3/'