On Thu, Dec 22, 2016 at 5:44 PM, Ullrich Hafner
wrote:
> I also do such plug-in integration tests before a release of my
> plugins, but I run them from the ATH.
There is a standing conflict between keeping all tests in one place,
vs. all in plugin repositories. Both have their pros and cons. As a
If you had the ath tests run using the Maven-failsafe plugin then `mvn
verify` would bypass polluting you local repo and *ensure* that the ATH
tests are actually using the "to be released" version by removing the clean
install hack
(Though I personally dislike the style of tests that people write
Hmm, I also do such plug-in integration tests before a release of my plugins,
but I run them from the ATH. Are there also some of your tests in ATH? (So that
we see if Jenkins core breaks something related to your plugin.)
Note that the ATH is not kept backward compatible in the same way as core
Running these tests prior to plugin release allows us to catch integration
issues before the plugin is released to the update center.
On Thu, Dec 22, 2016 at 4:14 PM, Ullrich Hafner
wrote:
> Am 22.12.2016 um 17:07 schrieb Scott Hebert :
>
> Hi,
>
> I wanted to share with the community a breakthr
> Am 22.12.2016 um 17:07 schrieb Scott Hebert :
>
> Hi,
>
> I wanted to share with the community a breakthrough with the JMS Messaging
> Plugin that other developers may find useful.
>
> Having been exposed to the Jenkins Acceptance Test Harness (ATH), I see great
> value in re-using the frame
Hi,
I wanted to share with the community a breakthrough with the JMS Messaging
Plugin that other developers may find useful.
Having been exposed to the Jenkins Acceptance Test Harness (ATH), I see
great value in re-using the framework to test certain aspects of a plugin
particularly in cases wher
