It is time for update!
The previous idea with the committed state and automatic cross-repo
merge hooks in zuul seems too complex to implement. So, the "CI gate for
blah blah" magically becomes now a manual helper tool for
reviewers/developers, see the docs update [0], [1].
You may start using it
Hi,
btw, right now we have 33 outdated astute.yaml fixtures for noop rspec
tests [0] - and this number is based on a single parameter of
network_metadata['vips'] hash, actual amount of outdated fixtures could be
bigger. So I've registered a new BP [1] to create a script that will
generate
On 02.12.2015 17:03, Bogdan Dobrelya wrote:
> On 01.12.2015 11:28, Aleksandr Didenko wrote:
>> Hi,
>>
>>> pregenerated catalogs for the Noop tests to become the very first
>>> committed state in the data regression process has to be put in the
>>> *separate repo*
>>
>> +1 to that, we can put this
On 01.12.2015 11:28, Aleksandr Didenko wrote:
> Hi,
>
>> pregenerated catalogs for the Noop tests to become the very first
>> committed state in the data regression process has to be put in the
>> *separate repo*
>
> +1 to that, we can put this new repo into .fixtures.yml
>
>> note, we could as
On 30.11.2015 13:03, Bogdan Dobrelya wrote:
> On 20.11.2015 17:41, Bogdan Dobrelya wrote:
>>> Hi,
>>>
>>> let me try to rephrase this a bit and Bogdan will correct me if I'm wrong
>>> or missing something.
>>>
>>> We have a set of top-scope manifests (called Fuel puppet tasks) that we use
>>> for
Hi,
> pregenerated catalogs for the Noop tests to become the very first
> committed state in the data regression process has to be put in the
> *separate repo*
+1 to that, we can put this new repo into .fixtures.yml
> note, we could as well move the tests/noop/astute.yaml/ there
+1 here too,
On 20.11.2015 17:41, Bogdan Dobrelya wrote:
>> Hi,
>>
>> let me try to rephrase this a bit and Bogdan will correct me if I'm wrong
>> or missing something.
>>
>> We have a set of top-scope manifests (called Fuel puppet tasks) that we use
>> for OpenStack deployment. We execute those tasks with
> Hi,
>
> let me try to rephrase this a bit and Bogdan will correct me if I'm wrong
> or missing something.
>
> We have a set of top-scope manifests (called Fuel puppet tasks) that we use
> for OpenStack deployment. We execute those tasks with "puppet apply". Each
> task supposed to bring target
Hi,
let me try to rephrase this a bit and Bogdan will correct me if I'm wrong
or missing something.
We have a set of top-scope manifests (called Fuel puppet tasks) that we use
for OpenStack deployment. We execute those tasks with "puppet apply". Each
task supposed to bring target system into
Here is a docs update [0] for the patch [1] - which is rather a
framework - being discussed here.
Note, that the tool fuel_noop_tests.rb Dmitry Ilyin wrote became a Noop
testing framework, which is Fuel specific. But the same approach may be
used for any set of puppet modules and a composition
10 matches
Mail list logo
