It should work!
I double checked and upgraded my personal instance and it works here. Did apt-get update complete succesfully?
Repo is here for double checking: https://packages.gitlab.com/gitlab/gitlab-ce
I double checked and upgraded my personal instance and it works here. Did apt-get update complete succesfully?
Repo is here for double checking: https://packages.gitlab.com/gitlab/gitlab-ce
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!?
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.
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