Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to check in private repositories?? #236

Closed
ghost opened this issue Oct 14, 2012 · 8 comments
Closed

How to check in private repositories?? #236

ghost opened this issue Oct 14, 2012 · 8 comments
Labels

Comments

@ghost
Copy link

ghost commented Oct 14, 2012

for example ("git@altranolabs.tklapp.com:somebundle.git") gives me "No valid/supported repository was found at the given URL"

thanks

@stof
Copy link
Contributor

stof commented Oct 14, 2012

@AltranoLabs do you have a valid composer.json in your git repo ? And can you paste the verbose output ?

@stof
Copy link
Contributor

stof commented Oct 14, 2012

btw, this should probably be report to Composer as Packagist has no reason to hold a private repo, given it is a public composer repository

@jketterl
Copy link

jketterl commented Jan 7, 2013

running into this too. in my case this is not about the packagist running on packagist.org but about a local/private packagist installation serving a corporate network.

i agree that private packages should not be listed in the public repo, but what about a private package repo (i.e. packagist)? isn't that a valid use case?

@Seldaek
Copy link
Member

Seldaek commented Jan 7, 2013

@jketterl as far as I know packagist should have no problem handling it, given that you make sure the web user has access to the private repo.

@jketterl
Copy link

jketterl commented Jan 8, 2013

couldn't get it to work unfortunately. i imported the deploy ssh key to the web users' .ssh folder, which allowed me to do a "git clone" on a private repository on the command line, but i couldn't import it into packagist.

i think i must add that i'm talking about private repositories on github. i read the code a bit, and as far as i can tell packagist will prefer the github api, which gives a 404 on private repositories.

is there a way to force packagist to use the regular git driver instead of the github one?

@Seldaek
Copy link
Member

Seldaek commented Jan 8, 2013

@jketterl this is strange, it should try a git clone if the api returns 404 and it's in non-interactive mode.

@jketterl
Copy link

jketterl commented Jan 9, 2013

i don't have any more information on this issue unfortunately, i tried searching for logfiles, but couldn't find anything relevant. is there a way to switch into verbose mode or something like that? the system has not gone anywhere near production yet, so basically i can configure it to whatever you tell me

@jketterl
Copy link

ok after digging around some more in the source code i found the real issue behind this one (and a solution, but i don't know if this will fix the OP's problem).

i installed packagist on a pretty much standard debian base system, which means that apache will start up as root (to get port 80) and then switch to user "www-data". so the first problem was that i installed the ssh-keys into the wrong location (it seems they have to be in /root/.ssh, which is actually pretty handy given that the home directory for www-data is /var/www).

your statement that it will try a git clone was true, however it still did not work because of the second problem i ran into: the debian default config does a "unset HOME" in /etc/apache2/envvars because (quoted from the file): "this won't be correct after changing uid".

so what basically happend when i tried to add a private repository is that packagist tried to create $HOME/.composer which evaluated to /.composer (due to the missing HOME variable). of course the user www-data was not allowed to do this, and so the checkout failed, too.

to fix this, i simply added the line "SetEnv HOME /tmp" to my packagist vhost definition, and now everything is fine :)

why did this not happen with public repositories? maybe because with public repositories on github, the api provides enough information, so that packagist does not even get to the point where it actually tries a git clone. this is just a guess however.

i thought i'd give you some detailed insight about this issue, since this could either be prevented by documentation, or even by checking the presence of the $HOME variable in code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants