Project

Profile

Help

Task #7411

Story #7416: [Epic] As a plugin user, I can use the next verison of pulpcore without upgrading my plugin

Add a new "test existing plugin against next pulpcore" entry to the CI matrix in plugin_template

Added by bmbouter 10 months ago. Updated 6 months ago.

Status:
CLOSED - COMPLETE
Priority:
High
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
CI/CD
Sprint:
Sprint 87
Quarter:

Description

Background

https://www.redhat.com/archives/pulp-dev/2020-August/msg00065.html

To Do

The plugin_template needs an additional matrix test that tests the current GA of a plugin against pulpcore master. This captures the "one ahead" situation where a user is using a newer version of pulpcore and the "one back" version of that plugin.

Associated revisions

Revision e8fe0068 View on GitHub
Added by dkliban@redhat.com 7 months ago

Adds a stage to test released plugin with pulpcore's master branch.

re: #7411 https://pulp.plan.io/issues/7411

History

#1 Updated by bmbouter 10 months ago

  • Parent task set to #7416

#2 Updated by daviddavis 10 months ago

  • Sprint set to Sprint 80

#3 Updated by rchan 9 months ago

  • Sprint changed from Sprint 80 to Sprint 81

#4 Updated by bmbouter 9 months ago

  • Sprint/Milestone set to 3.7.0

#5 Updated by bmbouter 9 months ago

  • Priority changed from Normal to High

#6 Updated by mdellweg 9 months ago

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?

#7 Updated by bmbouter 9 months ago

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.

#8 Updated by dkliban@redhat.com 9 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to dkliban@redhat.com

#9 Updated by bmbouter 9 months ago

  • Sprint/Milestone deleted (3.7.0)

#10 Updated by rchan 9 months ago

  • Sprint changed from Sprint 81 to Sprint 82

#11 Updated by pulpbot 9 months ago

  • Status changed from ASSIGNED to POST

#13 Updated by rchan 8 months ago

  • Sprint changed from Sprint 82 to Sprint 83

#14 Updated by rchan 8 months ago

  • Sprint changed from Sprint 83 to Sprint 84

#15 Updated by rchan 8 months ago

  • Sprint changed from Sprint 84 to Sprint 85

#16 Updated by rchan 7 months ago

  • Sprint changed from Sprint 85 to Sprint 86

#17 Updated by rchan 6 months ago

  • Sprint changed from Sprint 86 to Sprint 87

#18 Updated by dkliban@redhat.com 6 months ago

  • Status changed from POST to CLOSED - COMPLETE

Please register to edit this issue

Also available in: Atom PDF