Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-37288

option to continue processing dsl if an error occurs

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      As per https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/job-dsl-plugin/UHKrv2umo20/JqH0ELbYBgAJ, it would be really useful to have the option to continue processing job DSLs even if an error occurs in one of the groovy files, marking the build as unstable/failed of course.

      One good use case for this is that various organizations are using Job DSL to scan repositories and automatically find ones with groovy files (similar to Jenkinsfile) and create jobs for them, however it would be awesome if a groovy failure in one repository did not cause the rest to fail and stop generating, but only affected that team that has the syntax error.

        Attachments

          Activity

          Hide
          daspilker Daniel Spilker added a comment -

          This conceptually difficult. Depending on the setting for "Action for removed jobs", Job DSL will disable or remove any job that has not been generated. So if a script should generate job A and B, but fails to generate B, Job DSL can't decide if job B has not been generated on purpose (and should be disabled or deleted) or if it has not been generated due to an error (and should not be disabled or deleted).

          Show
          daspilker Daniel Spilker added a comment - This conceptually difficult. Depending on the setting for "Action for removed jobs", Job DSL will disable or remove any job that has not been generated. So if a script should generate job A and B, but fails to generate B, Job DSL can't decide if job B has not been generated on purpose (and should be disabled or deleted) or if it has not been generated due to an error (and should not be disabled or deleted).
          Hide
          mcrooney mcrooney added a comment -

          I agree and think there is a simple solution. The idea (at least to me) is that it degrades as gracefully as possible. So, it can continue doing other DSLs, but it is absolutely fine (and in fact preferred for me) that if an error happens processing a job or view, and continue is enabled, that this implicitly skips any job disabling/deleting. The build is definitely still broken so it is fine that it didn't get to the disabling/deleting step, the idea is that it at least finishes the job creation step as best it can (processing all the scripts), so that a rogue error in one script doesn't stop updating all the other jobs. Again, it should still fail and anyone responsible should still fix it, but with this option large orgs aren't nearly as hugely impacted by one syntax error. Just fail the build and don't move on to the job/view disabling/deleting step. What do you think?

          Show
          mcrooney mcrooney added a comment - I agree and think there is a simple solution. The idea (at least to me) is that it degrades as gracefully as possible. So, it can continue doing other DSLs, but it is absolutely fine (and in fact preferred for me) that if an error happens processing a job or view, and continue is enabled, that this implicitly skips any job disabling/deleting. The build is definitely still broken so it is fine that it didn't get to the disabling/deleting step, the idea is that it at least finishes the job creation step as best it can (processing all the scripts), so that a rogue error in one script doesn't stop updating all the other jobs. Again, it should still fail and anyone responsible should still fix it, but with this option large orgs aren't nearly as hugely impacted by one syntax error. Just fail the build and don't move on to the job/view disabling/deleting step. What do you think?
          Hide
          mcrooney mcrooney added a comment -

          Any thoughts on that solution as outlined? Seems like it work to result in a failed build that doesn't handle disabling/deleting, but still continues generating all the jobs it can.

          Show
          mcrooney mcrooney added a comment - Any thoughts on that solution as outlined? Seems like it work to result in a failed build that doesn't handle disabling/deleting, but still continues generating all the jobs it can.

            People

            • Assignee:
              daspilker Daniel Spilker
              Reporter:
              mcrooney mcrooney
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: