We will stop publishing bindings soon

x9c4 · July 1, 2024, 12:23pm

We are currently in the process to roll out our new version of generating the bindings.
This is the very process I would anticipate to see moved into the packaging process or even further down for installations using settings that affect the result.

github.com

pulp/pulpcore/blob/main/.github/workflows/build.yml

# WARNING: DO NOT EDIT!
#
# This file was generated by plugin_template, and is managed by it. Please use
# './plugin-template --github pulpcore' to update this file.
#
# For more info visit https://github.com/pulp/plugin_template

---
name: "Build"
on:
  workflow_call:

defaults:
  run:
    working-directory: "pulpcore"

jobs:
  build:
    runs-on: "ubuntu-latest"

This file has been truncated. show original

x9c4 · July 23, 2024, 10:48am

We are finished redoing the bindings generation in our pipelines the new way. And I am proud to say this process is by far easier than before.
The result however is the same insufficient artifacts we were shipping before. And we still plan to stop doing this.

Robin_Chan · July 29, 2024, 3:41pm

For those chiming in here on this post, take a look at this related post and please chime in if you have any ideas or thoughts.

x9c4 · October 7, 2024, 12:04pm

We hit another wall here:

github.com/pulp/plugin_template

Client generated with different pulpcore breaks lowerbound tests

opened 09:14PM - 03 Oct 24 UTC

pedro-psb

bug

## The problem Recently on rpm CI we got an error [on the lowerbound tests](h…ttps://github.com/pulp/pulp_rpm/actions/runs/11147495715/job/31044194248#step:15:6367) related to the [introduction of prns on pulpcore==3.63.0](https://pulpproject.org/pulpcore/changes/#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: ```bash $ # 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 ](https://github.com/pulp/pulp_rpm/blob/7a1d1a206efc6682029a003bc14626d24366c4dc/.github/workflows/scripts/script.sh#L47-L84) 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`)?