We know that certain types of failures are only going to occur on certain kinds of jobs. Especially when a mulit-line can is required, it is ideal if we an limit what jobs are scanned for a particular cause. Obvious ways to limit a job scanning are as follows:

      • By job label.
      • By Name (regex pattern match against name)
      • By job Type (maven, free style, etc.)
      • By what folder or view the job appears in.

      Some of these ideas are harder to implement than others and probably deserve their own ticket. The first two are easy and likely give the most ROI.

          [JENKINS-32686] Limit Scan by Job Label, Job Type, Name Etc.

          I assume that the main driver for this idea is to spend less time and resources on scanning?
          Sounds like a good idea and I agree, the obvious place to start is with the easy implementations e.g. job name.

          Tomas Westling added a comment - I assume that the main driver for this idea is to spend less time and resources on scanning? Sounds like a good idea and I agree, the obvious place to start is with the easy implementations e.g. job name.

          Perhaps, but the biggest bang for the buck is in the label one I think. We have windows slaves and linux slaves building very different things and they don't share much in the way of know build failures.

          Kenneth Baltrinic added a comment - Perhaps, but the biggest bang for the buck is in the label one I think. We have windows slaves and linux slaves building very different things and they don't share much in the way of know build failures.

          Some more thinking on the label one. It seems to me that if you allow KB entries to be labeled much the same way as slave nodes are labeled, then you should be able to use the same logic that determines "can this job run on this slave?" to determine "should this job's logs be evaluated against this indication?" Thus I can label a known docker error with the "docker" label and it will only be run against those jobs that would have run on my 'docker' slaves, for example.

          As for the saving processor time, yes, this is particularly important when doing multi-line indications. if I can tailor those to a very specific set of jobs, it would be great.

          Kenneth Baltrinic added a comment - Some more thinking on the label one. It seems to me that if you allow KB entries to be labeled much the same way as slave nodes are labeled, then you should be able to use the same logic that determines "can this job run on this slave?" to determine "should this job's logs be evaluated against this indication?" Thus I can label a known docker error with the "docker" label and it will only be run against those jobs that would have run on my 'docker' slaves, for example. As for the saving processor time, yes, this is particularly important when doing multi-line indications. if I can tailor those to a very specific set of jobs, it would be great.

          Maybe the BFA categories can be reused for this? By default, each project would be scanned for everything,
          but a project setting could tell BFA to only scan for failures that are part of certain categories.
          I feel like a new "label" concept in parallel with categories could be confusing, e.g. the failure cause
          "can't run docker for some reason" with category "docker" and label "docker".

          Tomas Westling added a comment - Maybe the BFA categories can be reused for this? By default, each project would be scanned for everything, but a project setting could tell BFA to only scan for failures that are part of certain categories. I feel like a new "label" concept in parallel with categories could be confusing, e.g. the failure cause "can't run docker for some reason" with category "docker" and label "docker".

          Sorry I dropped this thread but I would say I am cool on this solution. This means we would need to update every single job config and we have a lot more jobs that build failure entries. And the jobs are naturally categorized already by labels.

          In addition, we heavily use the categories and feed this data into or own analytic platform where we track what kinds of failures occur how frequently, which are trending, etc. So for us this would sort -of dual-purpose the category field and dirty up our analytics.

          Kenneth Baltrinic added a comment - Sorry I dropped this thread but I would say I am cool on this solution. This means we would need to update every single job config and we have a lot more jobs that build failure entries. And the jobs are naturally categorized already by labels. In addition, we heavily use the categories and feed this data into or own analytic platform where we track what kinds of failures occur how frequently, which are trending, etc. So for us this would sort -of dual-purpose the category field and dirty up our analytics.

          Any more motion on this? Would be super happy just to have the job-name-regex implemented.

          Kenneth Baltrinic added a comment - Any more motion on this? Would be super happy just to have the job-name-regex implemented.

          Sorin Sbarnea added a comment -

          I am interested about any way for enabling BFA to work on only a limited number of jobs. We have really fat Jenkins instances and enabling BFA on some of them is a always-postponed due to risks of affecting other jobs.

          Without a configurable way to limit BFA on some of the jobs we are stuck. A configurable way to do this would allow us to tune in-out its usage without having to enable/disable the entire plugin.

          Sorin Sbarnea added a comment - I am interested about any way for enabling BFA to work on only a limited number of jobs. We have really fat Jenkins instances and enabling BFA on some of them is a always-postponed due to risks of affecting other jobs. Without a configurable way to limit BFA on some of the jobs we are stuck. A configurable way to do this would allow us to tune in-out its usage without having to enable/disable the entire plugin.

            t_westling Tomas Westling
            kbaltrinic Kenneth Baltrinic
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: