-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Add a resume-ci
label to issues?
#40817
Comments
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made. |
This would still be useful |
I'm going to move this over to the core repo as CI triggering via labels is now done via Actions (https://github.com/nodejs/node/blob/master/.github/workflows/auto-start-ci.yml). I'm not sure if it's possible to resume a build in Jenkins before it has completed (i.e. any queuing would have to be self-managed). |
I can see how this would seem to be useful on the surface, and maybe it really would be, but I wonder if it would encourage resuming CI runs without looking at what actually failed. I could be wrong, but I would be cautious about the way the more we make it so that we don't check actual CI runs and just keep re-running them until they pass, the less useful we make CI. |
Instead of effort put into making such a label work, I would prefer to see a large effort put into making CI more reliable so that resuming runs is the exception rather than the rule. |
The functionality already exists in Jenkins, so if someone wants to resume CI without looking at the failures, they would do it regardless of the label. I don't see how just adding the label for convenience would encourage more of that.
I think people are already putting in the effort of making CI more reliable - there are currently 42 open issues and 427 resolved ones that have the
flaky-test
|
If anyone wants to attempt this:
For resuming you will need to add functionality to |
IIUC, the label means that Triagers can do it too, so it expands the pool of people that have access to the resume feature. This is good, but also has the potential for the unintended effect I noted.
Some people are, yes. But there is not a large coordinated effort like there was when the Testing WG existed, for example. And I think we need something like that. (You'll notice I'm not volunteering to do it, so I'm part of the problem here, for sure.) |
That shouldn't be necessary though. We can make use of the GH APIs to check if the person who added the label is a collaborator and then run the actions.
So we don't have a clear path to make CI more resilient? Just wanted to make sure if you were -1 about a PR landing that adds this feature at least for collaborators only. |
I'm not -1 on that or extending it to triagers. |
Hey, I'd like the TSC to discuss two things here (personal opinions below):
Regarding CI and landing things: Personally I think running CI posts some but not significant risks - and it means the TSC needs to decide how strict it wants to be about onboarding triagers . Landing things with the label is fine given NCU enforces reviews, green CI and a correct commit format. Regarding |
I think the TSC had decided that triagers are eligible to use commit queue to land PR. |
Great I didn't know that! Then just ci and the resume-ci label |
@Trott I'm wondering how we would do that in general. Mapping tests to which files they might be affected by is not obvious to me. The resume ci label seems useful to me as well, I share the concern over making sure we look at failures before resuming, but that might be handled by documenting or surfacing existing documentation that sets the expectations. I'd personally be fine with an expectation that you look at failures make sure there are open issues for them before resuming. |
Discussed in previous TSC meeting, see https://github.com/nodejs/TSC/blob/main/meetings/2022-03-10.md#nodejsnode and in #42125 Removing from TSC agenda as we think questions have been answered. |
Hey, not sure if this is the right place to ask (is it?)
There is a
request-ci
label which saves me the hassle of going to jenkins, entering all the details and starting a build for pull requests.It would be useful to me if there was a similar label for
resume-ci
(when most builds pass but one is flakey or failed due to an unrelated infra issue).Bonus points if it queues the "resume" even if the build didn't finish yet - but either way would save me time.
The text was updated successfully, but these errors were encountered: