Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client generated with different pulpcore breaks lowerbound tests #917

Open
pedro-psb opened this issue Oct 3, 2024 · 0 comments
Open

Client generated with different pulpcore breaks lowerbound tests #917

pedro-psb opened this issue Oct 3, 2024 · 0 comments
Labels

Comments

@pedro-psb
Copy link
Member

The problem

Recently on rpm CI we got an error on the lowerbound tests related to the introduction of prns on pulpcore==3.63.0.

The problem is that the lowerbound uses pulpcore~=3.49, which means it shouldnt have any prn stuff in this public API at all. And that's what the bindings diff says here:

$ # build-api.json was generated in the build step based on rpm installation like  "pip install rpm -c ci_constraints.txt"
$ # test-api.json was generated in workflows/scripts/script.sh, based on container env, which has also "-c lowebound_contraints.txt"
$ jsondiff --indent 2 build-api.json test-api.json || true
{
  "op": "remove",
  "path": "/components/schemas/rpm.ModulemdObsoleteResponse/properties/prn"
},
{
  "op": "remove",
  "path": "/components/schemas/rpm.ModulemdResponse/properties/prn"
},

So we are using the built-client (the client that was built in the build.yml step), which was generated using a different pulpcore version than the one in our test environement installation. I've heard of this problem several times, but had never experienced such a concrete example. Yet another "that's why we are stop publishing bindings".

Considerations

This code gives some warnings about this problem, and its where the client package is being selected.

But we can't know what pulpcore was used in the built-client (or its schema) at this point to make some kind of comparision because it doesnt show anywhere in the schema or package metadata (which is unfortunate, and maybe we should add this information on the schema, at least).

Anyway, I'm not sure what approach to take here. I'm assuming we want those to match, so maybe we could always use the client generate there (in the scripts/script.sh)?

@pedro-psb pedro-psb added the bug label Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant