Integrating GitHub status checks for pull requests.(GitHub Enterprise)

Continua CI Discussion
1

Hi Guys,

We’re trying to setup a pull request pipeline for automated tests to reflect in our GitHub’s server PR UI.
I’m not sure what’s missing or misconfigured, so I’d appreciate if you could assist :slight_smile:

I have added a build event handler for our tests configuration with the following setup:

GitHub API URL: https://<hostname>/api/v3/ (our local GitHub enterprise server installation)
Username/Password: a service account + 2FA Token in the Password Field.
Access Token: left this blank.
Repositories: OurRepo
Context: ci
When to run: first/last stage + complete on waiting promotion
Options: wait for results, log build messages.
Conditions: none

I’m not sure whether or not we’re supposed to do anything on the GitHub server side for this to work.
I have a branch protection rule for a test branch that has “Require status checks to pass before merging” checked (although ideally we do not want status checks to block merging, we just want to show them in the PR UI)
But just below that checkbox it says:

No status checks found
Sorry, we couldn’t find any status checks in the last week for this repository.

When I’m trying to (manually) run the Continua CI Configuration with the event handler I described earlier -
It immediately fails and the log reads:

Executing event handlers for ‘On Before Stage Start’ build event
Executing handler ‘github-test’ for build event ‘On Before Stage Start’
No enabled Git repositories with the name ‘OurRepo’ and a valid remote url were found associated with this build.
No enabled GitHub repositories were found associated with this build
Build failed while executing event handlers for ‘On Before Stage Start’ build event

Not sure if this is related, but the Continua CI Configuration has no triggers;
It is currently triggered manually on-demand only with the play button from the UI.
Also, in contrast to the message from the log, this configuration DOES have an associated repo named ‘OurRepo’ (Global Repository, used by many other configurations)
The repo is setup to NOT checkout files to workspace if it matters.
I tried enabling “Fetch other remote refs” for this repo with

+refs/pull/*/merge:refs/remotes/origin/pr/*

Waited for the changesets to be saved, and tried to manually trigger the build again - it failed with the same messages.
Also tried changing the refspec to:

+refs/pull/*/head:refs/remotes/origin/pr/*

but that triggered a ‘Repository’ system event that repeated on every repo update interval:

Repository Cannot get changes for repository @link(2002, <uuid>)[OurRepo]: Running ‘C:\Program Files\Git\cmd\git.exe’ with arguments “fetch --prune --all” failed with return code -2147483648 and error output: “The process timed out as there was no response for 20s 0ms. Process was running for 21s 614ms in total.”

So I reverted the extra refspecs back to the “merge” suggestion for now
Checking with “git ls-remote origin” I do see our pull requests as refs/pull/10016/head, so I have to wonder why it fails when this refspec is configured for that.

Any help would be much appreciated!
Continua CI 1.9.1.785
GitHub Enterprise 2.22.3

Thanks!
Arik

VP Edit : make discourse show full refspec!

2

Hi Arik

This would be the first issue to resolve. Is the repo ‘OurRepo’ associated with the configuration? I had a look through the code, it it looks the list of repos associated with the configuration at the time the build is created, and filters by repo type (git) and then by repo name, and also checks that it has a valid repo uri (cannot be a file based uri). Given the info you posted, I suspect the name is the issue.

The refspec looks correct - I thought it wasn’t, but it appears discourse is not displaying it correctly - when I copied it to quote here it showed the full refspec

+refs/pull/*/merge:refs/remotes/origin/pr/*

This will not fetch anything if the pull request resulted in any merge conflicts. Is your pr showing as able to merge? Also, if you have already merged, I believe it will not show as github usually deletes the merge ref after the pr is merged.

As for why the fetch prune is timing out, I’m unsure - it may be we need to allow a longer timeout on that call - will investigate.

We don’t have access to Github enterprise (I assume you are using the on premise version?) - I will investigate if we can get access to it (I’m guessing unlikely for on premise but might be able to access the cloud version).

It might be worth enabling debug logging so we can get a clearer picture of what is happening (send it to support @ finalbuilder .com).

1 Like
3

With regards to the fetch timeout, it looks like there is a bug in the git repository plugin that has it using the wrong property for the fetch timeout.

As a workaround, try increasing the Authentication Prompt timeout on the Options tab of the repo, 20s may be too short. We’ll look into this first thing tomorrow (it’s a holiday here today).

1 Like
4

Hi Arik,

There’s no bug related to the timeout, the Authentication Prompt timeout is implemented as designed. It is set to abort certain the git commands (fetch, pull, clone) with a timeout error if there is no output for 20 seconds.

This is to deal with issues where incorrect authentication details causes an authentication prompt. As the Continua CI service has no way to detect or respond to prompts, we abort the command, otherwise we can end up with a situation where the git command is left hanging.

It is possible that the fetch command may take longer than 20 seconds without any output, in this case the timeout needs to be extended. We are thinking of increasing the default timeout, so it would be interesting to know how long the fetch command takes to run with your repository. I suspect that it may be taking longer when fetching the pull request heads than the pull request merges - and this is why you are only seeing the timeouts in this case.

The likely reason for the No enabled GitHub repositories message is that the repository does not have a valid URI, according to the .Net Uri class. Is it possible that you are using an SSH url for your repository? If so, the standard GitHub SSH URL in the format git@github.com:ownerName/repositoryName.git is not currently accepted as valid by the Update GitHub Status build event handler. You can work around this by using the format ssh://git@github.com/ownerName/repositoryName.git instead.

We are currently investigating what changes we can make to accept the former SSH format.

Note that the build event handler is not affected by the checkout files to workspace setting or the presence of triggers.

1 Like
5

Thank you both so much!
The repository was indeed with a standard SSH URL
I changed it to the suggested workaround (ssh://) and after waiting ~30 minutes
(because our repo is large and it had to be re-initialized and all its changesets had to be saved from scratch) - I tested again and the event handler now works!

1 Like