Recently I removed the writing rights of a former collaborator who left our github project.
Then I noticed that in the commits page there was no more report for the continuous integration tests with AppVeyer( by clicking on the red cross or the green check).
I gave again the write permission to this former collaborator and the report for AppVeyer became visible again.
So I looked more carefully at the features related to AppVeyor and this former collaborator. I saw that:
in https://ci.appveyor.com/team at Account > Team > GitHub teams, I have not yet granted access to any GitHub teams and by clicking on CONFIGURE TEAMS I see that AppVeyor is authorized to act on behalf of this_former_collaborator GitHub account with admin:repo_hook, read:org, repo:status scope.
in https://github.com, for our organization, by editing, in Seetings > Third-party access, the AppVeyor CI application, I see "approval requested by this_former_collaborator".
What can I do to remove the write rights to our Github project from this former contributor while keeping the results of the ongoing AppVeyor CI tests on the project commits page (and don't lose the history of the tests)?
Thanks to the fast and efficient help of AppVeyor's support team I was able to fixe this problem by authorising AppVeyor as GitHub App. Everything works fine now ...
Related
I read the documentation about the GitHub integration in AppVeyor and one thing is still not clear to me:
When I want to use GitHub teams, do I still need to invite people to be collaborators in AppVeyor?
If so, how does it work with permissions? If both GitHub teams and users/collaborators are assigned to roles, what does take precedence? Eg. user is directly assigned to an "Administrators" role and also a member of a GitHub team with a lower set of permissions. Are the two sets of permissions combined somehow?
In other words, is it possible to manage access to AppVeyor only through GitHub teams? (Without having to invite users to AppVeyor.) If not, what's the point of GitHub teams integration...?
I configured several GitHub teams from our organization (Kentico) with certain roles in AppVeyor. However, the users belonging to the GitHub teams didn't see the Kentico account in AppVeyor when they signed in with their GitHub account.
You do not have to invite GitHub team members (though you can). They should see your account in top left drop down when logged with GitHub button.
If you still invite them, GitHub team role takes over role you assigned in invitation.
Yes, you should be able just use GitHub teams. When GitHub team member login into AppVeyor with GitHub button, hidden Collaborator automatically created.
Let us troubleshoot your specific users over support ticket you created on our forum.
I tried to:
Revoke access and authorize again at https://ci.appveyor.com/account/kentico/authorizations - DIDN'T WORK
Remove and recreate the GitHub team at https://ci.appveyor.com/account/kentico/github-teams - DIDN'T WORK
Verify that both AppVeyor and AppVeyor CI are authorized OAuth apps at https://github.com/settings/applications - DIDN'T WORK
Reinstalled AppVeyor from GitHub marketplace: https://github.com/marketplace/appveyor - WORKED
I am aware of similar questions (How to protect "master" branch in GitHub? and How can we enforce mandatory reviews in GitHub but still allow Maven release builds from CI?) and of GitHub's "protected branches" feature. Sadly, so far, I have been unable to come up with a solution that fulfills all our requirements:
only administrators and automated process accounts (like Maven release on Jenkins) can push directly to master
everybody else must open a pull request (which requires an approval)
everybody can merge approved pull requests
We are a small organization on a GitHub "Team" plan, and we're happy to switch plans, if necessary. However, I'd like first to make sure that whatever other plan we choose would actually support all these requirements.
I want to use Travis CI for personal projects, I would like to know if it is possible to prevent Travis CI to have access to an organization as a member and not an administrator.
If you have a Github account for yourself it is a personal account. That account can be a member or owner of any number of Github organizations.
If you are just trying to add Travis CI so that it has access to your personal repositories but not to the organizations you administer, you can do so easily.
When you sign in to the Travis CI website with your personal Github account for the first time, it asks you to "authorize Travis CI":
This page has an "organizations and teams" section that defaults to read-only (it can see what repositories etc your orgs have but cannot take any actions on them)
This page also has an "Organization Access" section at the bottom with a list of each Github organization you are a member of. As long as you do not click "request" or "grant" on any of those, your orgs will not yield any control to Travis CI.
If I try to click the “flip switch” next to a new repository in my Travis account, the flip switches but the hooks are never configured and I cannot trigger a build in Travis.
If I look at the console, I can read the following error:
XMLHttpRequest cannot load https://api.travis-ci.org/hooks/123456. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://travis-ci.org' is therefore not allowed access. The response had HTTP status code 500.
This may be linked to my GitHub organisation having activated third-party applications restrictions. Yet, all my previous repositories still build fine, and it's been weeks!
How can I start building a new repository in my Travis organisation account?
This is indeed linked to your organisation having third-party application restrictions, or “third-party whitelisting”.
You may not detect the problem at first since your current public repositories still receive web hooks, so it may be weeks before you get issues with Travis, and the connection with activation may be long lost in your mind.
So, now you've figured out these weird CORS/500 are linked to third-party application restrictions, you need to grant access to Travis again. But how? Travis has already been allowed access and won't ask you again for it upon login!
You have to go to your own user-approved application list in your GitHub profile, and click “View” next to the Travis-CI listing.
If you scroll down, you will get an “Organization access” listing. Your restricted organisation should be listed here, with a cross next to its name. Click “Grant access” to allow Travis into your org.
Everything should be in order now, and you should be able to activate Travis for your repo! You will just need to trigger a build by pushing a new commit after having “flipped the switch”.
I have an organization on GitHub with private repositories. I also have Jenkins set up running on port 8080 on a server, with the GitHub plugin installed. I've created an account on GitHub for my jenkins user, which resides in the owners group.
I'm trying to trigger a job on jenkins when a change is pushed to my development branch (or master branch, neither seem to be working).
When I look at the GitHub Hook Logs in Jenkins, it says that Polling has not run yet. When I go to "Manage Jenkins", the GitHub plugin says my account is Verified when I test it.
Any insight on how to configure this? I have multiple repositories I'd like to work with, so deploy keys don't seem like the solution to me.
Update:
As Craig Ringer mentions in his answer, you can select Grant READ permissions for /github-webhook in "Configure Jenkins" under the GitHub plugin settings, allowing the webhook to be called without authentication.
Another update: Webhooks are now (Dec. 2014) available for organization: see WebHooks API for orgs.
Note: the issue 4 of the hudson-github-plugin was about:
Last GitHub Push
Polling has not run yet.
And the conclusion was:
Nevermind, the only missing piece was a permission checkbox for the github user which ain't documented anywhere on the internet.
So is this a permission issue regarding your Jenkins users?
The article "Set up Jenkins-CI on Ubuntu for painless Rails3 app CI testing" includes the following process:
To restrict the CI system and give access to your Team members to use or see the build logs, first you’ve to create an account.
Go to Manage Jenkins > Configure System,
Check the Enable Security checkbox
Under Security Realm, choose Jenkins's own user database
Check the Allow users to sign up checkbox
Under Authorization, choose Project-based Matrix Authorization Strategy
Add first user with the name admin and another with GitHub (Note: the username for Admin access has to be admin) For GitHub named user, just choose the Overall Read only permission. We’ll use this user later with the GitHub hook.
Note: The admin and GitHub user that we’ve added in the above step does not create the User. Then you’ve to create a real user with that same name. Ya, I know, its a bit weird with Jenkins UI.
Go to Manage Jenkins > Manage Users > Create User. Create both admin and GitHub users.
Hooking with the Github web-hooks
Now to run the build automagically when new commit or branch gets pushed onto Github, we have to setup the repository.
Got to the hooks page for your repository. e.g.
github.com/<username>/<project_name>/admin/hooks
Under AVAILABLE SERVICE HOOKS > Post-Receive URLs, add github:github#your-ci-server.com/github-webhook/.
The github:github is the user that we’d created earlier.
Then we have to verify Jenkins with Github. Go to Manage Jenkins > Configure System and under GitHub Web Hook, add your Github username and password and click the Test Credential button to authorize once with Github.
It looks like the accepted answer is no longer necessary with the current version of the GitHub plugin. You can instead check Grant READ permissions for /github-webhook in "Configure Jenkins" under the GitHub plugin settings, allowing the webhook to be called without authentication.
As explained in the help on this option that's quite safe, and frankly no worse than having a user named "github" with password "github" anyway.
There are two ways to achieve automatic builds on Jenkins. What you choose depends on whether GitHub can call the Jenkins server URL you provide. This may not be the case if you are running Jenkins behind a firewall.
If GitHub can reach that URL you can set up the service hook on your repo there.
If not you can set up Jenkins to poll periodically.
You may set up both, but one solution is enough to get it working. I would always go for the first if feasible as it saves resources CPU and traffic wise.
Either way you need the GitHub plugin for Jenkins.
Hope that helps a bit.