To add it: `curl https://packages.gitlab.com/install/repositories/gitlab/gitl... | sudo bash`
If you expect someone to run their own git & ci server, is it so hard to give them a couple of dot-point instructions:
- create a .list file with these two lines: <blah>
- add the GPG key for Apt
- run aptitude/apt-get update
Sure enough, you're already listed on curl|sh (http://curlpipesh.tumblr.com), which also includes a link to the https://packages.gitlab.com/gitlab/gitlab-ce/install page which has a "manual" tab.
Even with "manual" selected, you still insist that people should make a http request to your server, to generate a .list file, even though the only variables are local variables, which you send as part of the request anyway: distro ID (e.g. Debian, Ubuntu, etc) and release codename (Wheezy, Jessie, etc).
The most ominous thing to me is that you send the result of `hostname -f` to your server. Even bigger WHY!?
Sending the hostname is default Packagecloud.io behaviour.
Your own download page states:
We recommend you set the name to the fqdn of the target node (the value of hostname -f on linux), but you can set it to whatever you want
If your company is recommending something, shouldn't you have a good reason why?
This seems like setup instructions for GitLab and I think it is unrelated.
Click the "Manual" tab, last paragraph of the 'deb' section.
The changes: 1.) Renamed hostname to unique_id everywhere, and added more prose around replacing unique_id with any unique identifier. 2.) Removed the unique_id code from install scripts for public repos (still exists in private repos) 3.) Modified the manual install instructions to be easier to follow, and not require a curl to the server for public repos. 4.) Added mirroring instructions for both YUM and APT.
Shipping in 1.0.23
I built packagecloud, which is what GitLab uses for hosting packages.
Getting a package repository installed securely is quite a bit more difficult than it seems, but I agree that our Manual install instructions should be simplified and improved. I'll see what I can do about making them better.
As far as the hostname goes: we used it simply because its a unique identifier for the machine, but really anything could be used (like a MAC address or whatever). This is used because private repositories have tokens issued against a unique identifier, so a machine reinstalling a repo won't generate a new read token. I'll add a comment to the bash script explaining this, and consider adding an override in the future so that users can specify another identifier of their choice instead.
This is why a request to the server is required: it generates a read token server side which is then implanted into the APT repository configuration for the local machine so that the local machine can access the repo.