Skip to content

Add a resume-ci label to issues? #40817

Closed as not planned
Closed as not planned
Add a resume-ci label to issues?#40817
Assignees
MoLow
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

Description

@benjamingr
benjamingr
opened on Nov 29, 2020

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.

Activity

  1. github-actions commented on Sep 26, 2021

    @github-actions
    github-actionsbot
    on Sep 26, 2021
    Contributor

    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.

  2. benjamingr commented on Oct 3, 2021

    @benjamingr
    benjamingr
    on Oct 3, 2021
    MemberAuthor

    This would still be useful

  3. richardlau commented on Nov 15, 2021

    @richardlau
    richardlau
    on Nov 15, 2021
    Member

    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).

  4. richardlau
    transferred this issue fromnodejs/buildon Nov 15, 2021
  5. richardlau
    added
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    on Nov 15, 2021

  6. Trott commented on Nov 16, 2021

    @Trott
    Trott
    on Nov 16, 2021
    Member

    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.

  7. Trott commented on Nov 16, 2021

    @Trott
    Trott
    on Nov 16, 2021
    Member

    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.

  8. RaisinTen commented on Mar 3, 2022

    @RaisinTen
    RaisinTen
    on Mar 3, 2022
    Member

    I wonder if it would encourage resuming CI runs without looking at what actually failed

    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.

    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.

    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 Issues and PRs involving tests that fail intermittently in CI. label but flaky tests seem to pop up every now and then. Writing more tests increases the chances of introducing flaky ones.

  9. richardlau commented on Mar 3, 2022

    @richardlau
    richardlau
    on Mar 3, 2022
    Member

    If anyone wants to attempt this:

    For resuming you will need to add functionality to node-core-utils. You would need to investigate if there is a Jenkins REST API end point for resuming a build.

  10. Trott commented on Mar 3, 2022

    @Trott
    Trott
    on Mar 3, 2022
    Member

    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.

    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.

    I think people are already putting in the effort of making CI more reliable

    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.)

  11. RaisinTen commented on Mar 4, 2022

    @RaisinTen
    RaisinTen
    on Mar 4, 2022
    Member

    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.

    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.

    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.)

    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.

  12. Trott commented on Mar 5, 2022

    @Trott
    Trott
    on Mar 5, 2022
    Member

    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.

  13. benjamingr commented on Mar 5, 2022

    @benjamingr
    benjamingr
    on Mar 5, 2022
    MemberAuthor

    Hey, I'd like the TSC to discuss two things here (personal opinions below):

    • Should triagers be able to land things and run CI from the GitHub labels?
    • Should Node.js add a resume-ci label?

    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 resume-ci: Given the CI is flaky and has been for 5+ years at different points I do see a lot of value in such a label or streamlining how CI runs with flaky tests better (that is: not just mark them flaky but logic like: "If this test fails everywhere and in only one architecture and is not in a file changed in this PR - automatically don't fail the CI on it")

  14. benjamingr
    added
    tsc-agendaIssues and PRs to discuss during Technical Steering Committee meetings.
    on Mar 5, 2022

  15. Ayase-252 commented on Mar 5, 2022

    @Ayase-252
    Ayase-252
    on Mar 5, 2022
    Member

    I think the TSC had decided that triagers are eligible to use commit queue to land PR.

    Refs: nodejs/TSC#1039 (comment)

  16. benjamingr commented on Mar 5, 2022

    @benjamingr
    benjamingr
    on Mar 5, 2022
    MemberAuthor

    Great I didn't know that! Then just ci and the resume-ci label

  17. mhdawson commented on Mar 10, 2022

    @mhdawson
    mhdawson
    on Mar 10, 2022
    Member

    is not in a file changed in this PR

    @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.

  18. mhdawson commented on Mar 23, 2022

    @mhdawson
    mhdawson
    on Mar 23, 2022
    Member

    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.

  19. mhdawson
    removed
    tsc-agendaIssues and PRs to discuss during Technical Steering Committee meetings.
    on Mar 23, 2022
  20. MoLow
    self-assigned this
    on Jul 19, 2022

  21. github-actions commented on Jun 27, 2026

    @github-actions
    github-actionsbot
    on Jun 27, 2026 – with GitHub Actions
    Contributor

    This issue has been marked as stale due to 210 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  22. github-actions
    added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 27, 2026

  23. github-actions commented on Jul 28, 2026

    @github-actions
    github-actionsbot
    on Jul 28, 2026 – with GitHub Actions
    Contributor

    This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
    If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

  24. github-actions
    closed this as not plannedon Jul 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

buildIssues and PRs related to Node.js builds or CI infrastructure.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions