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.
Related
Recently I tried to make a website using HTML and CSS and then I tried to host it on GitHub by commit under a repository name myname_examp.github.io, but when I tried to access it through the web browser using myname_examp.github.io there was an error 404.
Is there some steps to do?
If your Github account is free tire, the Github pages repo must be public.
If you are using GitHub Enterprise Cloud and has access control, the site can only be accessed by people with read access to the repository where the site is published from.
You can use actions status to check whether your site ready:
See more on Github docs
BTW, if your site is project type (repo not named user/org.github.io), you shall go to repo setting enable pages.
I want to know which of my repos are GitHub page enabled.
Is there any way to do this with API v3 or v4？
I am new to github. Sample code will be very appreciated.
You can use the GitHub API rpeos Pages
The GitHub Pages API retrieves information about your GitHub Pages configuration, and the statuses of your builds.
Information about the site and the builds can only be accessed by authenticated owners, even if the websites are public.
In GitHub Pages API endpoints with a status key in their response, the value can be one of:
null: The site has yet to be built.
queued: The build has been requested but not yet begun.
building:The build is in progress.
built: The site has been built.
errored: Indicates an error occurred during the build.
You can then force a GitHub Page repository to rebuild, through GitHub Action, if you want.
I'm building a Google Spreadsheet app where Google app script will commit the generated files into a git repository. Access is using an OAuth app, client id and secret.
Committing files to repo that I own works fine, but when I try to commit and push files to a repository I created under an organisation, it seems like the repo isn't there.
Error: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/reference/git#create-a-blob"}
Looking at both, the only difference between them is the URL used to access the API.
The one that works: https://api.github.com/repos/[my username]/[repo name]/git/blobs
Not working: https://api.github.com/repos/[org name]/[repo name]/git/blobs
Is there a separate API for dealing with organisation repo? I even created a public repo to test and it wouldnt work.
Found the solution.
The OAuth app access was denied as it was created with my account. Create the OAuth app with the organisation account instead.
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
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”.