ODS Dashboard / Visual Studio Code Extension

[cschweikert]

Up till today a usual project powered by ODS comes along with a zoo of tools scattered all over a given OpenShift cluster. All those tools offer interesting or important information about...

• running/successful/failed builds (Jenkins)
• unit test reports (Jenkins)
• OpenShift projects related to a project (OpenShift)
• routes related to OpenShift projects (OpenShift)
• code quality metrics (SonarQube)
• etc.

How about we make these pieces of information available inside the provisioning app and therby extend the provisioning app's scope into something like an ODS Dashboard app, where the provisioning topic is one part of.

Alternatively or even in addition (maybe by using the same backend API) we can provide an ODS Extension for VSCode. This would allow us to also trigger actions from there, e.g.

• enter Jira issue number and one-click >>self-assign+put "In Progress"+create branch in Bitbucket+git checkout<<
• one-click pull request creation: creates PR in Bitbucket from current branch in VSCode
• rerun Jenkins builds
• provision new component
• clone OpenShift project and rebuild it from current branch
• etc.

[michaelsauter]

@cschweikert Interesting :)

Who would be the user for this dashboard? Is this for developers, or managers, or ... ?

therby extend the provisioning app's scope

I'm a little worried by this ;)

• enter Jira issue number and one-click >>self-assign+put "In Progress"+create branch in Bitbucket+git checkout<<
• one-click pull request creation: creates PR in Bitbucket from current branch in VSCode

I like this! This should also be doable without extending the prov app, no? Maybe a good starting point for a hackathon?

[metmajer]

@cschweikert I am not too sold on the idea of enhancing the scope of the Prov App, partly because it's not going to be accessible in the near future in our enterprise context anymore. Component provisioning and environment cloning through a VSCode extension sounds like a cool thing. However, in our enterprise context, those activities are served through an ordering process. For the moment, I would not like us to open a backdoor to our users that enables them to work around our established processes. That said, OpenDevStack is an open source project, but I'd like to avoid creating unnecessary conflicts.