I know GitLab provides a built in package repository. Will we be using this?
Also, will it be possible to ping external package repositories (Packagist etc.) from GitLab, to keep packages up to date elsewhere?
Topic on Talk:GitLab/2020 consultation
Both of these questions might be a touch out of scope for the code review discussion, but then again they do seem to impinge on deployment, for some values of "deployment". Which is just to say that I don't have detailed answers but did want to make sure they're addressed all the same...
I know GitLab provides a built in package repository. Will we be using this?
We don't currently have any plans around that feature. I believe it's available in the Community Edition, and I can imagine finding uses for it at some point in the future, but it's not something we've discussed or tested extensively.
Also, will it be possible to ping external package repositories (Packagist etc.) from GitLab, to keep packages up to date elsewhere?
While I haven't explored this in detail, I think the answer is probably yes, one way or another. There are probably security policy considerations around credential storage and the like, but at minimum it's something you could do in a CI job if it wasn't supported any other way.
Thanks Brennen, that's sort of what I thought, but it's good to get it clarified. Certainly, the status quo with Gerrit is that it's frustrating to update Packagist, so it doesn't matter if it's also a bit tricky in Gitlab! :-)
A bit out of topic, but we can simplify the publishing to packagist.org. Packages hosting is really a different topic, I will give some context below.
Publishing to repositories will be equally tricky until we tackle the issue and add whatever logic is needed to update packagist after a tag is created :] That is definitely doable right now with:
- Gerrit might be enhanced with webhooks but I don't see how credentials get handled.
- we could have a CI job running after a tag is created which would poke packagist.org and trigger a crawl of the repository. I guess the devil is all about creating a user for this, add the user to the repository we maintain on packagist and craft the job that does a POST to packagist.org.
We had some discussions about self hosting our packages (eg running our own instances of packagist.org, npmjs.com) but instead went with snapshoting dependencies in vendor.git repository or relying on lock files when building Docker images. We have one for Java/maven world ( https://wikitech.wikimedia.org/wiki/Archiva ) and use that to deploy to production.
Having our own package hosting might let us deploy to production from them instead of relying on vendor.git snapshot, but with the move toward Docker images and lock files I guess it has less interest now. For composer/npm, we would surely have to also publish to packagist.org / npmjs.com which are the default indices saving people the trouble to have to refer to our reposiories. So I guess we collectively gave up on the idea :]
As a quick update re: Packagist specifically, I just noticed there's a Packagist integration out of the box.