Let me Travis-enable organization repos that I have admin priveliges in #242
Comments
|
I'll take a look at this one. Wrote it up here for record-keeping. |
|
Yeah, this is a big one for me. All of my repos I want on Travis-CI are in organizations that I own. |
|
@porras and I were working on this last friday and we have almost the work done, we are waiting to add some kind of badge identifying the repo as the one from an organization before pull-requesting. |
|
Doh. At least someone else did while I procrastinated. ;-) On Sep 27, 2011, at 3:46 PM, Sergio Arbeoreply@reply.github.com wrote:
|
|
It is quite complicated but we are still working on it. Please, be patient :D |
|
I'm pretty interested in this as well! All of my projects (that are not simply forks) live under an organization and I have not forked them to my personal account. |
|
Sorry for the delay. A quick status update is pretty much needed. Sadly, my spare time has been decreased this month, so I could not work enough on this. There are two problems:
Since 1 cannot be solved in Travis, finding a way around 2 is the way to go. @porras and I consider the project for orgs, finished, the problem is that there is no way to notify the user when Travis cannot add the proper hook to it. |
|
When you say, "there is no way to notify the user when Travis cannot add the proper hook to it," does that mean that the only missing part is having a way to automate this process?
Or is there something more to it? If not, I can say for myself I'd rather have to enter that manually on my own rather than wait for a way for this part to be automated. I would imagine that anyone who is doing Organizations is a sufficiently advanced user that they'd be able to configure this part properly. Would it be nice to have it automated? Yup. :) At the expense of not being able to hook into organization repos? Not for me... I took a quick look at the organizations API for GitHub and I can see how it might be difficult to try and figure out whether or not any given user actually has admin access to a specific repo. :) Anyway, I'm excited to give it a try. This looks like a great project! |
|
The automatization is done. The problem is, when you turn it on in the Travis panel, it goes on whether or not it is really done. There was no error handling in the SC part, but maybe that changed. @svenfuchs may know more about this. |
|
Ah, I see. I actually just enabled Travis on a random fork to see how it worked (so I could take the screenshot) and I noticed that disabling it in Travis didn't actually remove the hook (or even uncheck "Active") on GitHub. Unless I'm doing something wrong. :) I'm guessing that this "not sure if the hook is actually there or not" is a problem similar to what I experienced just a few moments ago. I don't know enough about Ruby to be 100% on this, but looking at Octokit it looks like it is currently using PubSubHubbub (only) for managing service hooks. I would imagine (and might be wrong) that you could issue a repos hooks list request and check results to see if Travis hook is listed (and activated). One thing I don't know is how synchronous the PubSubHubbub request would be? Would it be possible for the hook to not yet be registered by the time the second request is sent? My guess would be no, but I could be wrong. In any event, I suspect that this problem of not being able to determine whether or not the hook is actually added is not limited to just organizations? That is my guess after my recent experience (not being able to disable the hooks from the Travis dashboard) and after having a look at Octokit and the parts of travis that I suspect handles all of the service hook management. If any of this sound like it might be useful/on track, I might be able to contribute a bit of code to see if this works. My approach would be adding a second call after the subscribe_service_hook request here to ensure that the Travis hook was actually installed. Anyway, thanks for your feedback! Again, cool project. |
|
On further review, it looks like Octokit uses the v2 API and the hook related repository commands are not available in v2 but they are in v3. :-/ |
|
I pinged the Octokit project about v3 API support for repository hook commands. They are open to accepting patches to support the v3 repo hook API requests. So, unless I'm misunderstanding the issue here (it isn't clear to me what the acronym "SC" stands for), if you had a way to query a repository to see whether or not the hook is actually in place, you'd be set? If so, I'll see if I can try and get some traction on the Octokit project to support the v3 repo hook API. If I'm completely misunderstanding the problem, let me know and I can stop thinking about it for awhile and (try to) patiently wait for another solution to get organizations supported by travis. :) |
|
@Serabe hey, i'm wondering what the current status of this is? There were issues with reporting errors back to SC/Ember? Has this been resolved? |
|
+1 for this. Not easy to see where I'd go to view the CI output, either, as it doesn't show up in my account... |
|
Quick update. @porras and I were working on it but face a kind of big problem: Github API makes requesting the desired repos quite hard, requiring too many api calls. As a way around it we thought on just showing all public repos from your organization an try to fail gracefully when the user cannot add a hook to a repository. Sadly, travis had no code for it and our knowledge of SproutCore/Ember is not enough for anything, in particular, this task. |
|
Maybe pinging Github about this and asking for an appropriate API would be the best way forward? |
|
Sounds like something GitHub API should provide. |
|
@svenfuchs we did and we get answered that it was unlikely. Maybe coming from you would help the cause. |
|
as I understand, no organisation travis ci repo for now. What did GitHub guys said ? and what is the cost of this API calls ? Thank you ! +1 for this issue of coure. |
|
@gabrielstuff you just need to set up github hook manually for organization repos, it is documented. This is how repositories like rails/rails and joyent/node use travis. |
|
so far no luck with a proper github api for this. we need user/org sync for the paid service though. konstantin is working on improving our github api layer, so expect some news soonish |
|
Just chiming in that this would be wonderful. |
|
+1 (need an easier way to watch an issue) |
|
@rkh Any updates on this? |
|
Looking at the API, looks like this still isn't possible with the GitHub API without the sum of the number of teams associated with the organizations the user is a member of (if that makes any sense). How about we change this around, and instead of adding switches we have a text field at the top where you can enter the slug of a repo to add, and it'll fail nicely if you can't do it ("You don't have the permissions needed to enable Travis for this repository")? |
|
current master (i think) will display servicehooks for all repos you have read access to. we'll be able to filter this list so that it displays servicehooks for repos where you have admin access ... ie not organized by organization, but i think that's good enough for a while. we could then add some sort of pagination and search/filter field on top of that and i think we're golden. |
|
@svenfuchs does that mean that travis still cannot handle errors on client side? |
|
sure, that's a different issue, isn't it? |
|
Yep, but if there were some handling, a list of all repos from your organizations can be showed and fail gracefully if you cannot admin that repo. |
|
yes. we want to solve the root cause and not show repos where you're not an admin in the first place though. if you want to hop in and help fix this clientside, too, then please have a look at the ember-data branch which will (hopefully) soon replace the current master app. |
|
@svenfuchs it can be done, but it involves a lot of api calls right now. Seems that Github is not changing this soon though. Maybe some kind of caching? |
|
I am sorry, what can be done? I think I explained the current plan above. We'll be able to populate the current list with all repos where you have an admin role with a single API call, after Github has added an API for us. (Yes, we will more intelligently cache and pro-actively sync this in future, but that'll take a while and is yet another feature :) You were asking for communicating failures to the client which we'd appreciate a pullrequest for but which is a different topic. I might just not be following. Please explain in more detail what you are proposing unless it requires more work than our current plan :) |
|
Uhm, from my POV: @svenfuchs here: so far no luck with a proper github api for this Since then, the closest comment to "after Github has added an API for us" was this comment and it does not say anything about a custom API for Travis at all. So this answer refers to Travis ability to show organization repos. Several months ago, in irc I told you or @joshk that instead of making such a huge amount of calls, @porras and I thought about failing gracefully and letting the user knows that the repo could not been added. Is it another feature? Yes. Was it important for this feature? Yes, yes, yes, this comment says something too, etc. If there is a custom call from Github on the way, we shall just be patient and wait for it. |
|
Travis now lets you set service hooks for every repository you have admin rights too. You may need to log out and back in to see it. |
|
I'm not seeing this: going to https://travis-ci.org/profile/stuartpb only shows my profile and one of my organizations. |
|
Adding the hook manually to https://github.com/opensets/domainprofiles triggered a full refresh. |
|
(Note that I've since found out the problem was with my membership on the other organizations not being public - rather odd behavior nonetheless.) |
|
+1 @stuartpb for setting memebership to public, plus logout/login |
|
travis automatically detected my repos which were transferred to an oragnisation and all its build history have been kept and transferred. Cool! and Thanks for your hard work. |
/organization/repositories [GET] gives us most of what we'll need here. We only want repos where we have the "admin" permission.
The text was updated successfully, but these errors were encountered: