I joined a team recently were we all have similar Github permissions in a private repo from a team in an Org. For some reason whenever I merged it triggers jobs but no runners ever get assigned to actually run the job. So it finally fails after a timeout.
I have created a ticket Request #143718 but haven’t had a response yet.
Hi @kkarimi,
I replied to your ticket, but in case you didn’t see it or if another user experiences this issue, I’m sharing the reply here, too:
The behaviour you’re observing is caused by the VCS permissions check we perform, in order to confirm the user triggering the build has appropriate access.
We typically cache a user profile to speed up the permissions checks, but if the user doesn’t access the UI for a couple of hours the cache expires, and we have to build a fresh user profile the next time that user attempts to build.
In some cases, it can take up to a couple of minutes for that operation to complete, hence the build being delayed until we have the user profile that allows us to check permissions.
In rare cases, the operation might take too long or fail, causing the situation you’re experiencing.
A workaround we recommend is to implement a “heartbeat” API call in intervals so that the profile can be rebuilt before you are actively running jobs.
Essentially it would be a cron job that sends an authenticated API call to a CircleCI API endpoint (for example, the “User Information” endpoint) every hour or so.
Hi @yannCI thanks for response. However it makes no sense because I am talking about normal user experience in my ticket of using CircleCI graphical interface to check if a workflow succeeded or not, you seem to be talking about endpoint details which do not concern me as a customer just trying to use your product, what am I supposed to do? for now I have switched to another github user but I would have appreciated if someone had investigated why my github user had issues on those workflows. Thanks
Hi @kkarimi,
There might be some confusion here.
I only mentioned that API endpoint in the last paragraph of my reply to suggest a workaround. That endpoint isn’t in any way causing the problematic behaviour.
The issue stems from the need to “refresh” your CircleCI account’s cached data in order to map the permissions you have on the related repository.