> Am 27.04.2022 um 12:37 schrieb 'Antonio Muñiz' via Jenkins Developers
> <jenkinsci-dev@googlegroups.com>:
>
> I was working/planning with Oliver for some time on this. One of the
> identified downsides of this approach is that the Jenkins UI does often
> evolve in a backward incompatible way (ie. table to divs change, plugin
> manager recent changes, etc), all those potential breaking changes would not
> be caught by acceptance tests running at plugin build/release time (unless
> the plugin maintainer updates the `jenkins.version` to the latest very often).
When you run the ATH tests in a plugin then you run the tests agains the latest
Jenkins version, not the baseline version defined in the plugin. I’m using
Dependabot to make sure that this version is up to date. (It is still too late
since the Jenkins release is already published, but at least you will see it
one day after the release)
> The current ATH approach runs all acceptance tests against a specific Jenkins
> version, so possible regressions are caught at Jenkins core release time, as
> desired.
> The alternative would be to define the plugin build/release pipeline in a way
> that ATHs are run against a dynamic Jenkins version (could be the latest
> weekly at the time of the build), but that leads to unreproducible builds,
> which is IMO quite bad. And it does not address the issue of checking for
> regressions caused on plugins at core release time (unless some complicated
> pipeline is put in place to run ATHs from some key plugins as part of the
> Jenkins core build).
>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/C060C521-3E3A-4186-84EC-673A779FAFB2%40gmail.com.
