End-user testing hard-coded xml file - review and decide if they stay

[buep]

@bicschneider introduced two new commits

• 3c2178c
• 1baf81e

Our maybe re-introduced... could be, but we need to decide about if they stay or should be converted to real tests.
if it is something personal not giving value to developers or users of the plugin, I'll consider to remove it again.

They might have been discarded because we didn't understand them or because documentation was missing. I can't say for sure.
I'll review it and figure out if they are needed in our next release.

[MadsNielsen]

My view on this is that we should leave these two commits as-is. The only thing that did change is the fact that his commit fixes the issue with matrix jobs and our publisher, as in: We must only delete branch in the parent job, not in the child runs. So without this commit, our publisher will not work for matrix jobs.

[MadsNielsen]

The other files, as in the xml and the scripts carry no risk to the plugin. Those are useful tools if you want to construct jobs from xml and some documentation on how our plugin picks up commits. So those could be useful in some situations.

[buep]

Good catch @MadsNielsen with the matrix job publisher. It is something we will keep, but I think it needs to contribute something to the documentation as well. It can't stand-alone.

I'll make sure that we mention this implicit behavior, which is different from expected, in our documentation around support for matrix jobs.

The end-user testing, I'll have to look more into.

[bicschneider]

They could be JobDSL'ed and then only have one seed job ..

[buep]

That will lower the maintenance at least.