Closed praqma-thi closed 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.
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.
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.
Could you please not work as release Praqma guys? Use private sessions in your browser or two browsers, or just be thorough ;-)
How do this issue end?
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.
@Andrey9kin - you are the original request of this in #18 - how do want to continue?
@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
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?
@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.
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?
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.
Closing this. I've put my comments in #18
From #18:
Note that this still needs a milestone