ExtensionPoints are an important part of the JS side of plugins in blue ocean, they should be documented in terms of what data they can get passed and where they are hosted.

In scope:

• Find a scheme to document extension points, including param types
• Find a mechanism to generate static docs from source of what extension points are available, and what module, and publish
• Find a mechanism to dynamically enumerate extensionpoints and current implementers in a running jenkins instance on a "special" URI

IN https://github.com/jenkinsci/blueocean-plugin/pull/521

I take the point which leads to "contract properties" passed to certain ExtensionPoints. ATM we do it on free guess and all properties are passed through anyway.

However we do not have API style declarations of extension points and the attributes we pass through. Which makes it hard for adopters to create reliable alternatives for our default implementations.

I say ATM the graph is the only use case that we know of that had used run.id in a certain point of time. For housekeeping I prefer to get rid of it since it is redundant now because we pass full run.

As started I see your point, but see as well the urgent need to declare ExtensionPoints as API where we can deprecate certain attributes to later drop them. ...and to document them to start with.

in case you see the urge michaelneale please assign to final implementer otherwise just close it.