Pulp

I am a bit unsure, what the consequence of this test failing should be. As the breaking change here will most likely be introduced by pulpcore, does it mean the corresponding change (in pulpcore) must be reverted and delayed to the next minor release? Who is seeing the failure and reporting that pulpcore didn't follow the deprecation policy?

Is this test supposed to run with all pipelines, or only nightly?

mdellweg wrote:

I am a bit unsure, what the consequence of this test failing should be. As the breaking change here will most likely be introduced by pulpcore, does it mean the corresponding change (in pulpcore) must be reverted and delayed to the next minor release? Who is seeing the failure and reporting that pulpcore didn't follow the deprecation policy?

Is this test supposed to run with all pipelines, or only nightly?

It's up for debate, but here's my take. This check would be in the nightly of each plugin. It can only catch errors where pulp/pulpcore:master has already merged the problem. Then when it fails, the plugin writer needs to let the core team saying, "hey you broke me please revert on master".

It's unfortunate that this can only occur post-pulpcore-merge, but the other option is running every plugin's code against every pulpcore change which I believe is infeasible. Since the CI check in the plugin isn't checking changes in the plugin's code itself, I don't see running it pre-merge (versus cron) as productive. This leads me to the conclusion that this should be a nightly cron CI run in plugins.

PR: https://github.com/pulp/plugin_template/pull/267