Looking at getting deployment integration for http://www.codebasehq.com/
David Ebbo tweeted us to open a ticket here because the API/Hooks are non-standard (https://twitter.com/davidebbo/status/270917637599551488)
@jackhayter There is some related information here.
The first thing to discuss is the service hook. Does Codebase support that in a way similar to Github/Bitbucket/Codeplex? Tricky thing is that each site sends a different payload when it fires the hook, so we'd need to support specifically what your hook sends.
I just created a test Codebase account, and I'm not quite seeing where to do this. The closest I found is the Deploys button which points to Capistrano instructions.
There is a page in our docs about Post-Receive hooks here: http://support.codebasehq.com/kb/howtos/repository-push-commit-notifications
These can be set up from "Repository Admin/Properties"
Ah great, missed that! So it looks like the payload is the same as Github's, right? If so, that'll make things easier, and it might just work as is.
Specifically, try this:
Question: If Codebase gets an error when it fires the hook, is there a way to retrieve that?
There are some small changes we need to make to our hook handler for it to work. #225 tracks this.
Does Codebase only support private repos, or is there a way to make them public as well?
The payloads are fairly similar as far as I know. If the hook fails, we log (but don't display) errors. An appropriate HTTP status code is sent back though. If this behaviour needs alteration, we can do this quite easily.
Codebase has limited support for public repos. A public read-only HTTP access can be enabled on a per-repo basis.
I'll let you know how I get along with trying things out in Azure.
Okay, so having followed your instructions, I get an internal server error response. See: http://sdrv.ms/QYc1EC
At the moment I don't have any access to more details (but presumably Azure wouldn't divulge that information anyway?)
@jackhayter right, we found a small incompatibility in the payload, so we need to make a change on our side to make it work (tracked by #225).
Once we have that, manual setup steps should work. Then there is the question of getting more complete UI support in the Azure portal. Do you guys have an OAuth API that can be used to do things like:
@davidebbo That's great. I'll keep an eye on that ticket.
Our API does support all three of those actions, however it uses HTTP basic rather than OAuth.
Access and Authentication
How essential is OAuth? So far we haven't had a great demand for it, but if you guys need it, we'd be happy to look into it.
Thanks for the info!
So I guess the alternative to OAuth is that the user would enter their Codebase API key in the Azure portal? The benefit of OAuth is that it can potentially give finer grain access, and more importantly it is revocable. e.g. user can grant API access to several sites, and later decide to revoke access to just one of those sites. If they all share the same API key, you can't do that.
@davidebbo This is very true. We'll get that implemented then. I'm assuming you're after OAuth 2.0?
@jackhayter Yes, 2.0 is probably better (easier to work with).
Note that as a first step, we'll make the change on our side to fix the manual hookup cases issue discussed above, and that doesn't require OAuth.
When it comes to listing Codebase on the portal, I need to sync up with some other folks to make sure the UI can easily accommodate that. I'm sure we can find a way to get Codebase on there once you have OAuth, but it may take a bit longer.
@davidebbo as ssh is currently supported, shall I create a parser which defaults Codebase to private repositories and take the clone url from:
"ssh":"firstname.lastname@example.org:test/test-repositories/git1.git", // SSH clone URL
@remcoros My concern there is that even though Kudu supports ssh, it's only usable if we have a private key, which we don't always have. So in case the repo happens to be public, using ssh is not a good choice as that would prevent it to work without having the key, which should not be required.
So the question for @jackhayter is: for codebase, how can we tell a public from a private repo in the hook payload? With GitHub, private repos have a "private": 1 that we look for. Maybe for Codebase, the presence of an ssh URL means it's private? Actually, when I tried Codebase, my repo was private, and I'm not sure how I could have made it public (only saw an option for public changelog).
If we can detect it's public, that's fine.
Also, with this #185 in, you would be able to display the key in the portal, with the instruction to add it as a deployment key (which I think all or most providers support)
@davidebbo @remcoros Codebase now includes a public_access boolean in the Repository hash of the payload. If it is set to true then the repo can be read with HTTP, but we would always recommend using SSH anyway.
Repos on Codebase are private by default, and almost everyone leaves it that way. It is possible to set public access using the menu located here: http://cl.ly/image/2f3o311P0h3M
We'll look at getting OAuth in place soon as well.
@jackhayter Ok, I see the public option now. I was looking for it under Admin.
Given that your hook format is very similar to Github's, why not use the exact same why of indicating private repos? They use "private": 1 as a repo property in the payload.
It would make every consumer's life easier if all the git hosts were able to standardize on that payload :)
@davidebbo That flag was added this morning :)
Using the same as Github would make a lot more sense. I'll talk to my colleague who added this and see if we can toggle it over.
while you're at it, having a User-Agent header other then 'Ruby' could also be helpful.
Sure. What would your preference be?
Codebasehq.com ? just to be able to differentiate from others.
Sure. I'll pass this on.
Looping in @darkphnx, the developer responsible for this.
@jackhayter trying to see where we stand on this. Do you know whether those changes were done on your side? Specifically, using private flag instead of public_access, and changing the user agent to Codebasehq.com.
@davidebbo Sorry, that slipped off the radar over Christmas. That change has now been deployed to production.
@jackhayter Good news, I just tested this and it worked great. The setup phase is pretty manual, but it shows that we are making sense of the payload.
Specifically, the set up steps are is in this page:
We can look into portal support separately in the future once you have Oauth, etc...
Note that this change is in Kudu, but is not yet live in Azure, unless you use private Kudu bits