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”.
Related
I've installed the Google Cloud Build app from Github Marketplace, and enabled it on several repositories, only to discover that enabling access for those repositories automatically starts running the Google Cloud Build "check" after every PR or push to a PR. Since some of those repositories are not actually ready for Google Cloud build, I needed to turn off the checks... I used the URL mentioned in the docs to get to the page where you can select which repositories should be connected to your GCP project, and unchecked a bunch of them... this disconnected them from the project, but, surprisingly, did not disable the Github checks! So now, there are Github checks on several repositories that just result in an error because they're not connected to any projects in Cloud Build.
Surely, it is not an uncommon use case to need a way to "disable Checks" on a per-repository basis - is there any way to do that?
(If not, consider it a requested feature if there are any Google Engineers reading!) ;)
I did talk to chat support, and the only way we could figure out to remove the checks would be to uninstall Google Cloud Build completely from the entire organization, which I don't want to do because we do have some setup that I want to keep, and I don't know how much of that configuration would have to be redone if I uninstalled it completely.
Here is a screenshot of the broken check that I can't disable:
I think there are 2 steps to disable CloudBuild,
1. Disable on CloudBuild itself. For some time I kept seeing 2 builds per push made, but disabling a trigger on CloudBuild helped fix that.
2. On Github, you can configure the Cloudbuild app to monitor a specific repo on the organization level setting.
3. If you feel a lot adventurous though and it's not solved, on the project level setting, you could delete the Webhooks integration for cloudbuild, as that's what Github notifies of each build.
It can be found within GH App installations:
https://console.cloud.google.com/gcb-github-registration
Select the GH account used for your link between Cloud Build and GH, then the GCP project you want to edit.
Here connected repositories can be edited, and in the second step (Trigger settings), the "Default GitHub Checks" can be disabled.
You can also goto settings of your repository and click installations inside settings.
And then remove Google cloud build from Installed apps and authorized github apps.
Cloud Build Triggers are still in beta, and have gone through several updates since this question was posted, but it now appears that the "Github Default Checks" are no longer hidden from management. They are now explicitly offered (but not automatically created) when connecting a repo, and you can finally view and disable (or delete) individual "Github Default Checks" on the trigger management page: https://console.cloud.google.com/cloud-build/triggers
I'll leave this as unanswered, because I'm uncertain this is how it is working for everyone, or that this answer will remain true, but if it works for you, feel free to vote up the answer!
To link GCP Project to the Github repository, create a trigger by clicking on resolve link, besides Action Required and then disable the same. For me this procedure worked out.
I have a GitHub App set up to pull some data, authenticate with an installation token, and commit it to the associated repository every day. I would like this new data to be available on the GitHub Pages site for the repo which requires a GitHub Pages build. The GitHub App has read & write privs assigned on "Repository contents" and "Pages".
It appears that the daily commit is attempting to rebuild the page as in the repository's GitHub Pages settings after the daily commit I see:
Your site is having problems building: Page build failed.
An empty commit with my primary account (not the GitHub App) after a failed build triggers a successful rebuild as seen below.
October 23-25, 2018:
https://github.com/btouellette/HHHFreshBotRedux/commits/master
Nothing in the GitHub documentation about these generic build failures (https://help.github.com/articles/generic-jekyll-build-failures/) appears relevant as I am not using a deploy key, the primary account the GitHub App is installed on has a verified e-mail address, and I'm only pushing static files and not using Jekyll at all.
Since I'm already authenticating with the GitHub API to commit the file I attempted to utilize the API endpoint to manually request a page build (https://developer.github.com/v3/repos/pages/#request-a-page-build). The documentation says this endpoint is enabled for GitHub Apps but when I attempt to call it I get the response "Resource not accessible by integration".
Is there some way to address the build failures, to get the page build API endpoint working with the GitHub App, or to find another way to make new files available on the GitHub Pages site progammatically?
By using 'basic' authentication in octokit and providing explicit user and password I'm able to successfully request a pages build. The build endpoint is enabled for GitHub Apps but only for user-to-server requests where the app is acting as a user with user credentials.
Alternately I found that I can reference the raw content in the GitHub repository directly rather than using relative links from within the GitHub Pages site. This works but having the files in the pages build is better as they are served via CDN.
So by using full URLs like:
https://raw.githubusercontent.com/btouellette/HHHFreshBotRedux/master/docs/daily/20181025.json
Instead of relative URLs for the GitHub Pages site like:
"daily/20181025.json"
I'm able to grab files in Javascript that have not been added to the GitHub Pages build but have been made available in the repository and use them to build out the site dynamically.
Using the official guide, created build project to run tests on GitHub PullRequests creation. The webhook is correctly shown on GitHub, builds are being triggered in Codebuild, however, the build status is not shown in Github, despite the option Report build status is set true. If I correctly understood the tutorial, Codebuild has native support of GitHub, and after successful creation of a webhook, the new verification check should be added for PR submission automatically, any suggestions to make this work?
It should work automatically. If builds are triggering but codebuild is not reporting back on the status, then it sounds like the codebuild project no longer has permission to the repo. You could try adding the GitHub source to codebuild again.
"Report build status" actually has no effect when triggered by a webhook, and should always report back in theory (https://docs.aws.amazon.com/codebuild/latest/userguide/change-project.html). It's set to false for my project and always updates the pull requests.
Ensure the GitHub user has write access to the repository, and if you're using a Personal Access Token (PAT), ensure the repo:status scope is granted:
Grants read/write access to public and private repository commit statuses. This scope is only necessary to grant other users or services access to private repository commit statuses without granting access to the code.
https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/
(I experienced this issue recently. The PAT had the necessary scopes granted but the GitHub user had read-only access to the repository. Granting the GitHub user write permission solved the problem.)
We are hosting some repository on GitHub, some other on GitLab.
Sometimes, the package is published but not the source code.
We always display build status and code coverage in README.md.
Is there a way to have build and coverage badge on GitLab always accessible to anonymous?
Since release 11.4.8 of Gitlab it's not possible to expose project's Badges through a Personnal Access Token anymore. Because of the change "
Restrict Personal Access Tokens to API scope on web requests."
The commit that removed this "workaround" was published as a security fix
An ongoing issue is currently being discussed to find another solution. Let's see how it goes.
That was followed by issue 13324
It includes:
FYI, I have a workaround for this using the GitLab API.
It assumes you have created a token in GitLab for a user (Note: That "user" needn't necessarily be Human - my use case is to display a badge on a dashboard hosted on a different VM).
<img src="https://<gitlab-uri>/<namespace>/<project>/badges/<branch>/build.svg?private_token=<token>
Update Dec. 2018: This is no loger possible through a token (see Paul B.'s answer).
This is because of "Improper Enforcement of Token Scope":
The GitLab web interface was vulnerable to an authorization issue that allowed access to the web-UI as a user using their Personal Access Token (PAT) of any scope.
The issue is now mitigated in the latest release and is assigned CVE-2018-19569.
But...:
Updated: 2018-11-28: We have received reports that this change has impacted how repo files and job artifacts are downloaded for some users.
For instructions on how to do so through the API, please see our support issue.
And you also have a current workaround which repeats the API access:
It is possible to add the project avatar to the project repository with a particular filename (logo) and then this file will be used for the avatar. There is an example here:
https://gitlab.com/issue-reproduce/project-avatar-repo
You'll be able to retrieve the files through the Repository Files API:
https://docs.gitlab.com/ee/api/repository_files.html#get-file-from-repository
Example:
https://gitlab.com/api/v4/projects/issue-reproduce%2Fproject-avatar-repo/repository/files/logo.png?ref=master
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.