On úterý 6. června 2017 9:54:12 CEST Tomas Strachota wrote:
> On Mon, Jun 5, 2017 at 4:14 PM, Lukas Zapletal wrote:
> > On Mon, Jun 5, 2017 at 2:48 PM, Tomer Brisker wrote:
> >> My suggestion is that we replace the katello test currently running on
> >> every PR with a test that installs the top
On Mon, Jun 5, 2017 at 4:14 PM, Lukas Zapletal wrote:
> On Mon, Jun 5, 2017 at 2:48 PM, Tomer Brisker wrote:
>> My suggestion is that we replace the katello test currently running on every
>> PR with a test that installs the top 5 plugins together and runs all of
>> their tests.
>
> +1 +1 +1
>
>
On Mon, Jun 5, 2017 at 2:48 PM, Tomer Brisker wrote:
> My suggestion is that we replace the katello test currently running on every
> PR with a test that installs the top 5 plugins together and runs all of
> their tests.
+1 +1 +1
Last week or two, Katello was red because of trivial regression in
Hi,
It would be best, in my opinion, that we are able to tell as soon as
possible that some change will break plugins, and for that we'd need to run
tests on PRs.
My suggestion is that we replace the katello test currently running on
every PR with a test that installs the top 5 plugins together an
We currently run plugin develop tests only on Sunday, I assume this
has something to do with capacity planning. Today I stumbled upon
another taxonomy related regression in develop which broke Discovery
tests, I had to git bisect it until I found the commit in core,
Jenkins was only able to tell me
While I agree, one thing that properly defined plugin DSL does not solve is
the fact, that plugins now depend on each other. Few examples
openscap, katello depends on remote execution
katello, remote execution, ansible, chef, ... depends on foreman tasks
remote execution depends on foreman templa
On Thu, Jun 1, 2017 at 10:18 AM, Tomer Brisker wrote:
> Hello,
>
> While it is plugin maintainers responsibility to keep their plugins up to
> date, one of the most common frustrations they face is "core changed and
> broke something AGAIN". I wouldn't want to slow down core's already slow
> merg
Hello,
While it is plugin maintainers responsibility to keep their plugins up to
date, one of the most common frustrations they face is "core changed and
broke something AGAIN". I wouldn't want to slow down core's already slow
merge process, but at the same time core contributors should try to
min
On Thu, Jun 1, 2017 at 2:55 PM, Eric D Helms wrote:
> This sounds good in theory, but I'll refresh the history of why we did this.
> A change would be made to Foreman core, that change would go in and then
> propagate out. A developer would update their foreman checkout or the
> Katello pipeline w
On Thu, Jun 1, 2017 at 8:17 AM, Timo Goebel wrote:
>
> Am Donnerstag, 1. Juni 2017 12:17:49 UTC+2 schrieb Lukas Zapletal:
>>
>> I would like to open discussion about having a unit test job of
>> foreman with all major plugins enabled (katello, discovery, bootdisk,
>> rex, openscap).
>>
>
> What
Am Donnerstag, 1. Juni 2017 12:17:49 UTC+2 schrieb Lukas Zapletal:
>
> I would like to open discussion about having a unit test job of
> foreman with all major plugins enabled (katello, discovery, bootdisk,
> rex, openscap).
>
What would be all the major plugins? Expire Hosts? Digitalocean? Om
11 matches
Mail list logo
