-
Notifications
You must be signed in to change notification settings - Fork 10
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
Action produces hundreds of failed builds #27
Comments
Not sure, someone will have to look at the GitHub actions docs to see if the If we can't make the YAML more selective (which is what I'd expect), we should at least make it exit gracefully rather than emit an error.
No idea... |
It seems like However, I tried it at sympy/sympy#23801 and I can't get it to work. Any suggestions? It's super annoying to test this since it has to be merged into master before it actually does anything, so I'd prefer to minimize the number of iterations here. Or if you have a better way to test the action out that would be helpful. |
I would test it out by iterating by cycling through two steps
Every dummy commit you push in step (2) should immediatly allow you to see if step (1) had the effect you wanted. Once it does, you can open a PR to merge your |
I was looking into this as well. I think See also https://stackoverflow.com/questions/67330220/trigger-github-action-after-circleci-workflow-or-job. |
In some sense yes, because it has to look at all status events to find the right one. In another sense no, in that it does work without needing to make any changes to your CircleCI config...
... unlike this solution. I think this would require anyone who wanted to use this solution to add such a dispatch to their CircleCI job. So I think we could advertise two ways to do it:
@rgommers I think you might be able to try the repo dispatch approach (2) on SciPy already by modifying the CircleCI job to dispatch the event, and modify the |
I might give this a shot in this repo. It'll be easier and way less noisy than trying it in SciPy :) |
I think this might not be tractable. To launch a GitHub repo event, whatever emits/posts the https://docs.github.com/en/rest/repos/repos#create-a-repository-dispatch-event You can do this via:
For (2) to work, a maintainer would need to create a personal access token with access to the repo, put this in the CircleCI config, and make this visible/accessible/usable by forked PRs, which is unsafe because anybody could in the CircleCI job |
Argh, that's not nice. Agreed that this sounds too risky. Thanks for looking into it! |
It still might be possible to make this work with |
Maybe with #32 ? |
Maybe we should open a feedback issue about this at https://github.com/community/community/discussions/categories/general-feedback |
Now that we start using access tokens anyway, I wonder whether this could be fixed, too? #27 (comment) |
I am not optimistic because of this part of that comment:
|
Ahh, I was way too enthusiastic than a careful reader then. |
To follow-up: I could skip running the workflow for non-circleCI related jobs with a conditional in I also tried to use |
I just ran into this (though I got 4 jobs instead of hundreds?) but the end result is the same (no preview). Any workaround I can use? Thanks! |
@pllim - having stalling jobs, I wonder if the tokens are rotated properly? Note that I run into the multiple triggers, but haven't yet seen what you run into yet. (I certainly saw #58, but as I recall those were around only at the time when I was setting up a repo so not everything were at their right place). |
Keep in mind GHA is having a bad day https://www.githubstatus.com/ |
This comment was marked as resolved.
This comment was marked as resolved.
For completeness: #59 (comment) |
If you look at https://github.com/sympy/sympy/actions/workflows/docs-preview.yml, you can see there are a ton of failed builds for the docs preview action. I think this is because it runs every time there is a status change from any CI job, but it only makes sense when the status change actually comes from the CircleCI job.
Is it possible to make the action not run at all in these cases? It's obviously not a huge issue, but the current way is fairly confusing, and makes the "all workflows" list harder to read https://github.com/sympy/sympy/actions.
By the way, do you know why half of those jobs are indicated as being started by me, even for commits that I had nothing to do with? How does GitHub determine who the author of a "status" update is?
The text was updated successfully, but these errors were encountered: