You nailed it! Thank you.
The bindings, as well as the ansible-modules I am in the process of
developing are trained to be _nice_ to the api. So I would say, they
are ok to test the happy flow for some dedicated workflows.
But when it comes to testing with bad request, you probably need to
handcraf
The whole point to having generated bindings is to prevent a client-tool
from passing bogus data into Pulp, failing early and loudly so the
client-author can *fix their code/assumptions*. Yes, that does make it hard
to use the generated bindings to test bad-data-cases - but to me, that's
just the p
On Tue, Feb 11, 2020 at 6:04 PM Lubos Mjachky wrote:
> Dear colleagues,
>
> functional tests are currently being refactored to use bindings in various
> plugins. This will eventually allow us to query Pulp in a more pythonic way
> instead of using raw REST API calls, or pulp_smash utilities.
>
>
I opened a draft pull request that replaces None with empty strings, it
would allow getting manifest data even when it does not have a config_blob,
but I'm not sure if it is the best approach for this problem.
https://github.com/pulp/pulpcore/pull/536
Best regards,
Fabricio Aguiar
Software Enginee
Dear colleagues,
functional tests are currently being refactored to use bindings in various
plugins. This will eventually allow us to query Pulp in a more pythonic way
instead of using raw REST API calls, or pulp_smash utilities.
While refactoring the functional tests in pulp_container, I noticed
