Make a pipeline build itself

[bwijsmuller]

The ultimate proof that this thing can work properly, Pipeline should be hosted somewhere and build the pipeline code.
I realize that this requires a web GUI etc, but I think it is worth the early effort since this will create exposure and attracts users/developers.

[pvdissel]

Thanks for the reminder, it's something we need to work towards. In minimal form, we need the email notification configuration to be separated from the pipeline config, and maybe have a notifier that sets the build status back to github.

The separation of configuration like email server settings currently has the biggest focus together with the DSL/model separation. These are part of issues #4, #7, #24
After that's in, we can look at having pipeline building pipeline.

But it's already easy to try it for yourself with a private github or gitlab repo, just follow the few steps on the installation and configuration wiki pages. As soon as pipeline is ready for it, we will build pipeline with pipeline and show it off.

[beddari]

👍

[pvdissel]

@bwijsmuller What do you think, would that work for you? Would the "notifier to set the build status back to github" be a good first thing to show Pipeline works?

[bwijsmuller]

Well, maybe it is. I was thinking more of a read only web gui, like a build
monitor, that reads from pipeline. This should then be hosted at tricode
maybe?

On Tue, Oct 29, 2013 at 8:19 AM, Patrick van Dissel <
[email protected]> wrote:

@bwijsmuller https://github.com/bwijsmuller What do you think, would
that work for you? Would the "notifier to set the build status back to
github" be a good first thing to show Pipeline works?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-27282594
.

[pvdissel]

I see a web gui as a next step, but when starting with a gui the read-only web gui may be a good first step.

What info would you like to have minimally in the read-only web gui?

• status: success, failure
• log output

For the hosting I will just set-up an EC2 instance or something.

[bwijsmuller]

Since I'm thinking of a build monitor, like something to display on a
public monitor, I would not even expect log output.
Minimally, for each configuration (lets start with all), i expect:

• identification of the last few (say 3) build attempts
• build outcome for those attempts (success/failure/other?)

And then of course displayed with some nice eye-candy :D
Maybe something like AngularJS can be used to render something nice based
on information read from pipeline.
This information could be formatted as JSON for instance, which seems to be
pretty ubiquitous nowadays.
The gui requires some kind of way to read the information. A super simple
small REST service would do the trick. I don't know if this information
publishing service should also be a plugin?

I imagine, for the gui part, to be a plugin to pipeline, or extension or
whatever you call it ;) that holds all of this stuff including that it
could run an lightweight embedded jetty to publish all this to the web.

On Wed, Oct 30, 2013 at 11:39 AM, Patrick van Dissel <
[email protected]> wrote:

I see a web gui as a next step, but when starting with a gui the read-only
web gui may be a good first step.

What info would you like to have minimally in the read-only web gui?

• status: success, failure
• log output

For the hosting I will just set-up an EC2 instance or something.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-27378950
.

[pvdissel]

Yes, I think we're one the same line here. My idea was/is to have an (REST) API service which just receives the same events the rest of the services will receive. This service can then handle the storage/caching/etc that it needs to provide its data to the requestors.
And any gui can then communicate via the API service.
(very good micro-services presentation: http://www.infoq.com/presentations/Micro-Services)

No plugin/extension of any kind, Just an additional service.

So ok, in it's minimal form we don't need log output.
Sounds good :)

Do you have suggestions for good, simple, REST API frameworks/set-ups, etc?

Currently the pipeline listener uses DropWizard (http://dropwizard.codahale.com/), which is really:

• include dependency
• create main service class
• create main config class
• GO
  As they say on their site "out-of-the-box support for sophisticated configuration, application metrics, logging, operational tools", and it is. Everything is based on common frameworks like Jetty, Jersey, Jackson, Metrics, Guava, Logback, Hibernate Validator.

I like it, but maybe there are even better?