-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[server][github] fix file provider for self-managed GHE #13108
Conversation
started the job as gitpod-build-alex-adjust-url-being-used-to-fetch-9253.0 because the annotations in the pull request description changed |
started the job as gitpod-build-alex-adjust-url-being-used-to-fetch-9253.1 because the annotations in the pull request description changed |
@AlexTugarev During testing, while creating a project from my personal repo in GH, I see this error message: As a result, the project seems to be there, but it does not receive any prebuild triggers... any idea why? 🤔 |
Unfortunately, not. I tried to reproduce with a fork of that repo, but it worked fine. @geropl, please repeat, as I just enabled debug logging for server. /hold Because of this report, and I'm not able to tell if this is unrelate, though it seems. And because I forgot to remove dead code. |
@AlexTugarev seeing this in the logs:
|
@geropl, could you please try again and use a different repo? I guess your test repo had see a lot of webhooks already 🤷🏻♂️ The error event is likely fired from there, thus not related to this PR. Let's tell the issues apart 🙏🏻 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With different repository I see prebuilds working as expected
/hold in case any other check is required 🙃
This is then subject to a bug with webhook installation on GH repos. cc. @jankeromnes, in cause you've encountered 422 error codes before? |
/hold cancel |
Description
This PR removes URL construction for reading file contents, instead rely on supported REST API.
Related Issue(s)
Fixes #9253
How to test
Though this claims to fix an GHE issue, it can be verified with GitHub SaaS as well, because the core issue was that we'd used to craft the download URL, but here we're changing to supported means of fetching contents via REST API. That said, if should be sufficient to test .gitpod.yml being read from any GitHub repo in a prebuild of a project.
Release Notes
Documentation
Werft options:
Valid options are
all
,workspace
,webapp
,ide