Preflight command to show config-repo definition

[ankitsri11]

Notes from @marques-work:

Essentially, this is a dupe of #9 (which I just closed in favor of this issue because this one has more context/convo.

Summary of #9:

It would be nice to have a visual representation of the effective hierarchy created by the config after the preflight call returns.

---

It would be nice to have a preflight command to display the config-repo definition such as:

• List down number of pipelines
• Show pipeline definition

Examples:

• Add config-repo
  ./gocd config 'path/to/config-repo/directory'

• List down number of pipelines
  ./gocd configrepo show config-repo

Output:

Pipeline1
Pipeline2
Pipeline3

• Show pipeline definition

./gocd configrepo show config-repo pipeline1

Output:

Pipeline1 
(material1:url)
(material2:url)
├── stage1
│   ├── job1- task1 (command)
              task2 (command)
│   └── job2- task3 (command)
              task4 (command)
├── stage2
│   └── job1
└── stage3
    ├── job1
    ├── job2
    └── job3

/cc: @arvindsv

[arvindsv]

@ankitsri11 We could also consider it a response of the preflight check (with a verbose flag).

[arvindsv]

That way it'll feel more natural.

[kierarad]

@arvindsv @ankitsri11 I agree that a verbose flag would feel more natural. I think I get the idea behind the pipeline list, but I'm slightly confused by the pipeline definition. How does the output differ (or is it the same) from the contents of the file(s)?

[arvindsv]

@kierarad The way I see it, it's a confirmation of what the GoCD server has seen. It might become more important when templates are introduced (as is happening here).

It could also help in cases such as gocd/gocd#5775 which is based on a real-life failure in feedback.

[kierarad]

@arvindsv got it! Thanks for the additional context. I didn't even consider the case in which no files matched.

[marques-work]

It might be good to make this machine-readable output as well (e.g., JSON). That way, people who want to make integrations to their IDE could get output that's useful.

Even better if the config represents only what the server "sees", which may be different than what the user sends (e.g., a user may have included a key that is in the wrong place, or is not understood, but ignored by the server)