In https://issues.jenkins-ci.org/browse/JENKINS-56996 we isolated errors in PR scanning to make them not crash the scan overall. We should isolate other errors as well.

          [JENKINS-57492] Isolate errors during SCM scanning

          Liam Newman created issue -
          Liam Newman made changes -
          Description Original: In https://issues.jenkins-ci.org/browse/JENKINS-56996 we isolated errors in PR scanning to make them not crash the scan overall. We should isolate other errors as well.

          New: In https://issues.jenkins-ci.org/browse/JENKINS-56996 we isolated errors in PR scanning to make them not crash the scan overall. We should isolate other errors as well.

          I did some digging on this and it is not particularly easy.

          I'd love to be able to simply catch and swallow some error locally, but if we do that it may result in jobs being deleted (or marked for deletion) simply because there was an error while reading them. I looked pretty carefully and I didn't see a way to address this safely in a small/local change.

          The core problem is that the code that controls how child items are created and maintained is spread across several other plugins, including folders, scm-api and branch-api.

          My thought is that we'll need to add a no-op preserve(String itemName) method to SCMHeadObserver.

          Then we can wire through an implementation in MultiBranchProject.SCMHeadObserverImpl.

          Finally, we'd expose that in github-branch-source for the GitHubSCMSource to call when an error occurs.

          I suppose it would okay for PRs specifically to simply be deleted on FileNotFoundException specifically, but not great behavior.
          Liam Newman made changes -
          Description Original: In https://issues.jenkins-ci.org/browse/JENKINS-56996 we isolated errors in PR scanning to make them not crash the scan overall. We should isolate other errors as well.

          I did some digging on this and it is not particularly easy.

          I'd love to be able to simply catch and swallow some error locally, but if we do that it may result in jobs being deleted (or marked for deletion) simply because there was an error while reading them. I looked pretty carefully and I didn't see a way to address this safely in a small/local change.

          The core problem is that the code that controls how child items are created and maintained is spread across several other plugins, including folders, scm-api and branch-api.

          My thought is that we'll need to add a no-op preserve(String itemName) method to SCMHeadObserver.

          Then we can wire through an implementation in MultiBranchProject.SCMHeadObserverImpl.

          Finally, we'd expose that in github-branch-source for the GitHubSCMSource to call when an error occurs.

          I suppose it would okay for PRs specifically to simply be deleted on FileNotFoundException specifically, but not great behavior.
          New: In https://issues.jenkins-ci.org/browse/JENKINS-56996 we isolated errors in PR scanning to make them not crash the scan overall. We should isolate other errors as well.

          Wow.
           I did some digging on this and it is not particularly easy.

          I'd love to be able to simply catch and swallow some error locally, but if we do that it may result in jobs being deleted (or marked for deletion) simply because there was an error while reading them. I looked pretty carefully and I didn't see a way to address this safely in a small/local change.

          The core problem is that the code that controls how child items are created and maintained is spread across several other plugins, including folders, scm-api and branch-api.

          My thought is that we'll need to add a no-op {{preserve(String itemName)}} method to {{[SCMHeadObserver|https://github.com/jenkinsci/scm-api-plugin/blob/6a044fe60143278ed26f8d91b0ec1cee116617d6/src/main/java/jenkins/scm/api/SCMHeadObserver.java#L43]}}.

          Then we can wire through an implementation in {{[MultiBranchProject.SCMHeadObserverImpl|https://github.com/jenkinsci/branch-api-plugin/blob/ed229d8e1392645c99e5686b8bd652a14ec87f4a/src/main/java/jenkins/branch/MultiBranchProject.java#L1948]}}.

          Finally, we'd expose that in github-branch-source for the {{GitHubSCMSource}} to call when an error occurs.

          I suppose it would okay for PRs specifically to simply be deleted on {{FileNotFoundException}} specifically, but not great behavior.

          Liam Newman made changes -
          Link New: This issue is related to JENKINS-56996 [ JENKINS-56996 ]
          Liam Newman made changes -
          Description Original: In https://issues.jenkins-ci.org/browse/JENKINS-56996 we isolated errors in PR scanning to make them not crash the scan overall. We should isolate other errors as well.

          Wow.
           I did some digging on this and it is not particularly easy.

          I'd love to be able to simply catch and swallow some error locally, but if we do that it may result in jobs being deleted (or marked for deletion) simply because there was an error while reading them. I looked pretty carefully and I didn't see a way to address this safely in a small/local change.

          The core problem is that the code that controls how child items are created and maintained is spread across several other plugins, including folders, scm-api and branch-api.

          My thought is that we'll need to add a no-op {{preserve(String itemName)}} method to {{[SCMHeadObserver|https://github.com/jenkinsci/scm-api-plugin/blob/6a044fe60143278ed26f8d91b0ec1cee116617d6/src/main/java/jenkins/scm/api/SCMHeadObserver.java#L43]}}.

          Then we can wire through an implementation in {{[MultiBranchProject.SCMHeadObserverImpl|https://github.com/jenkinsci/branch-api-plugin/blob/ed229d8e1392645c99e5686b8bd652a14ec87f4a/src/main/java/jenkins/branch/MultiBranchProject.java#L1948]}}.

          Finally, we'd expose that in github-branch-source for the {{GitHubSCMSource}} to call when an error occurs.

          I suppose it would okay for PRs specifically to simply be deleted on {{FileNotFoundException}} specifically, but not great behavior.

          New: In https://issues.jenkins-ci.org/browse/JENKINS-56996 we isolated errors in PR scanning to make them not crash the scan overall. We should isolate other errors as well.

          Liam Newman added a comment -

          I did some digging on this and it is not particularly easy.

          I'd love to be able to simply catch and swallow some error locally, but if we do that it may result in jobs being deleted (or marked for deletion) simply because there was an error while reading them. I looked pretty carefully and I didn't see a way to address this safely in a small/local change.

          The core problem is that the code that controls how child items are created and maintained is spread across several other plugins, including folders, scm-api and branch-api.

          My thought is that we'll need to add a no-op preserve(String itemName) method to SCMHeadObserver.

          Then we can wire through an implementation in MultiBranchProject.SCMHeadObserverImpl.

          Finally, we'd expose that in github-branch-source for the GitHubSCMSource to call when an error occurs.

          Liam Newman added a comment - I did some digging on this and it is not particularly easy. I'd love to be able to simply catch and swallow some error locally, but if we do that it may result in jobs being deleted (or marked for deletion) simply because there was an error while reading them. I looked pretty carefully and I didn't see a way to address this safely in a small/local change. The core problem is that the code that controls how child items are created and maintained is spread across several other plugins, including folders, scm-api and branch-api. My thought is that we'll need to add a no-op preserve(String itemName) method to SCMHeadObserver . Then we can wire through an implementation in MultiBranchProject.SCMHeadObserverImpl . Finally, we'd expose that in github-branch-source for the GitHubSCMSource to call when an error occurs.

            Unassigned Unassigned
            bitwiseman Liam Newman
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: