3

There's a vast variety of ways for connecting Jenkins jobs to other jobs (e.g., triggering, copying artifacts, promotion criteria etc). Is there a way to (reliably) determine which Jenkins jobs refer to a given job X? (Or, conversely: which jobs are referenced by a given job X?)

I tried heuristics like grepping all config.xml files for job name X, but this is not reliable of course. E.g., that catches job names in text/comment sections, and it will miss references that are not stored in the job config.xml files (like settings for the promoted-builds plugin).

I'm not interested in checking for specific kinds of references (this is simple once you know the corresponding XML format or the internal connection on object level). I wonder if there's a way to check for any kind of reference between jobs in a generic way.

As background, there's several use cases where you may want to determine which jobs are "connected" in some way, e.g.:

  • Cleaning up your job inventory: you want to delete obsolete jobs, but before deleting, you want to be sure that no other job still depends on it.
  • Packaging a collection of jobs (including all its dependencies) for a customer
  • Updating references to some job X that has been replaced or moved to some different folder.
Alex O
  • 7,746
  • 2
  • 25
  • 38
  • Why not running on *.xml from root folder and searching for ">x<" ? it'll catch any reference to the job in any xml. What we did is push all config files for jobs and plugins to a git repository, and used OpenGrok to index them, it is way easier to keep track on any changes in the jobs. – Dvir669 Dec 07 '16 at 11:56
  • Well,that's basically the heuristic I'm using so far -- but this will also catch e.g. `X` in description fields. It may also fail to catch cases where `X` does not appear as a plain single XML tag value (e.g., where it's part of a blank-separated item list that's stored as string, or where some different encoding/referencing scheme is used). I'm really looking for a semantic solution here, that does not depend on (re-)parsing the config file syntax. – Alex O Dec 07 '16 at 13:20
  • Have you tried the jenkins api `$JENKINS_URL/job/$JOB_NAME/api/json`? – Rik Dec 07 '16 at 14:37
  • Understood. If I would want to automate this I would either way have to run it once, see which results I'm getting and add regular expressions for exceptions. As you mention - this question is very specific to your use-case :) good luck! – Dvir669 Dec 07 '16 at 14:58
  • 1
    Mh, maybe the use case is not so special -- imagine that you'd like to delete abandoned Jenkins jobs, but before deleting a job, you want to be sure that no other job still depends on it. Or: you want to package a job and all its dependendencies for a customer. Or (my case : ) you want to move a job to a folder, and need to find out which other jobs have to be updated to account for the folder path. – Alex O Dec 07 '16 at 15:53
  • @AlexO Did you find a way to do it ? – devops Jan 09 '19 at 14:23
  • No, unfortunately I did not find a way. – Alex O Jan 09 '19 at 15:18

1 Answers1

0

Can't you do something similar to this: Get Jenkins upstream jobs

That way you can just see which jobs are triggered by upstream?

Similar for downstream: List all downstreams project for a project in jenkins

Community
  • 1
  • 1
MaTePe
  • 936
  • 1
  • 6
  • 11
  • Yes, I am looking for something _similar_, yet generic: Your proposal links to a method that checks for downstream projects _specifically_ (and not for any other kind of relation between projects). I'm looking for a solution that accounts for _any_ kind of relationship between projects -- it is not feasible to implement specific checks for hundreds of plugins that potentially connect two jobs. – Alex O Dec 07 '16 at 16:09
  • Ok, sorry, not really sure why you want it and why you can't be more specific. It is as you say, you can connect between jobs in multiple ways, but from my point of view the upstream/downstream should be enough. – MaTePe Dec 08 '16 at 08:30
  • Thanks. I added a few example use cases to clarify the motivation for this question. From those it should be clear that up/downstream relations will not be sufficient for finding jobs that are connected in _any_ way. – Alex O Dec 08 '16 at 10:33