Praqma / pretested-integration-plugin

A generic pretest commit plugin for Jenkins CI
MIT License
7 stars 14 forks source link

Investigate Pipeline support (case 14834) #21

Closed praqma-thi closed 8 years ago

praqma-thi commented 8 years ago

From #18:

There's a [big checklist](https://github.com/jenkinsci/pipeline-plugin/blob/master/DEVGUIDE.md) of points your plugin should adhere to if you want to start supporting Pipeline. 

We'll have to go through the entire checklist with the code at hand and list all the changes we'll have to make, changing the easy ones as we go along. There's a few points on the checklist that may cause some issues, like being unable to rely on AbstractBuild/AbstractProject.

I think we should spend a large on it, have me and Mads discuss and tackle it for half a day and see what we get out of it. It's a quick way to get a decent overview and information to plan on how to support it, at least.

Note that this still needs a milestone

MadsNielsen commented 8 years ago

Some notable things to consider. I think this one needs to be split up into smaller parts.

One issue we have is that we depend directy on the ability to obtain the configured SCM (and the configured git client) for the job, using getScm() on AbstrcactProject<?,?>. I cannot seem to find this method on Job<?,?> which is more generic.

buep commented 8 years ago

Add it to your checklist of investigations and take it into this issue where you actually investigate it. Can we do that? You already presented the problem... so we need to look at like the checklist, is it easy to fix or not.

ReleasePraqma commented 8 years ago

This is going to be difficult, if not impossible to implement:

We make heavy use of .getScm() on AbstractProject<?,?> object in one of our plugins, is there a way to obtain the same information from the more generic Job<?,?> ?

You mean, say, from a `WorkflowJob`? No, and the question does not
even make sense, because there need not be any permanent or unique
answer. To be compatible, your plugins would need to be reconceived
somehow.
buep commented 8 years ago

Could you please not work as release Praqma guys? Use private sessions in your browser or two browsers, or just be thorough ;-)

buep commented 8 years ago

How do this issue end?

MadsNielsen commented 8 years ago

I think this issue can be closed. All the things we need to take care of are described in the link above posted by @praqma-thi AbstractProject<?,?> to Job<?,?> and AbstractBuild<?,?> to Run<?,?>. These things are minor compared to the issue i listed above with the .getScm() part. A workflow job does not need to have an SCM configured, and the SCM can be placed in any context, making it dynamic and not static as in the FreeStyleJob. In a FreeStyle job, even if you have selected NO scm, you get a special NullSCM type.

The only way, that i can see in the short term, to get Pretested to work with workflow is to add and explore if a Git plugin SCM extension can do the same.

buep commented 8 years ago

@Andrey9kin - you are the original request of this in #18 - how do want to continue?

Andrey9kin commented 8 years ago

@buep can we check @MadsNielsen 's suggestion about Git plugin SCM extension? I would like to see a conclusion - either yes it is doable, and we can fix it using this and that or no it couldn't be done

buep commented 8 years ago

What do you mean Mads? Do you mean that we should re-implement the functionality of pretested integration as a Git SCM extension so it becomes one of the dropdown behaviors?

MadsNielsen commented 8 years ago

@buep I was hoping i could re-use existing methods, so that a re-implementation wouldn't be necessary.

But i think this requires a design descision, and planning, because there is quite a bit risk involved in doing what i proposed, and i'm not even too sure my proposal is the correct solution. I don't know how to approach this issue in a good way.

buep commented 8 years ago

Okay, so conclusion is we want to add our pretested integration to Git SCM as an extension (becomes one of the dropdown behaviors) to see if this solves the problem of getting pipeline plugin support.

I know it have been discussed earlier, to do that with @lakruzz, and I think we didn't want that.

Further I think the risk is high, using time on something that we don't even know will work (I assume here we are talking at least more than 2 days of work).

I suggest we investigate (in another issue) more about the pipeline job types and Jenkins model behind those, to know how it in general affect our plugins etc. To me it seems we don't really know much about the new things?

buep commented 8 years ago

I would like a short conclusion on #18 and to close this issue which now can be considered done - investigation done, we have a conclusion.

MadsNielsen commented 8 years ago

Closing this. I've put my comments in #18