Project

Profile

Help

Issue #2751

Unittest builder for plugins fails if the minimum required platform version is unavailable

Added by ttereshc over 3 years ago. Updated over 1 year ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:

Description

When plugin requires Pulp core version to be >= X.Y, builder tries to install version X.Y which may not exist for certain boxes.

Example.
OSTree plugin requires Pulp core to be >= 2.10, so builder tries to install Pulp 2.10 on F25 system but fails [0] because we do not have pulp-2.10 build for F25.

The PR builder job for plugins should be modified to:

1) Install the latest GA core RPMs and test against those. If they pass then pass the PR[UPDATE] This is already done; see the first associated commit.
2) If there are failures, retest using packages from the nightly build of Pulp. It's possible that there is new code that is required from platform that is not yet released. If this passes, then pass the PR

[0]: https://pulpadmin.fedorapeople.org/jenkins/jobs/unittest-pulp_ostree-pr/builds/40/node-type=f25-np.txt


Checklist

Associated revisions

Revision 32687f05 View on GitHub
Added by dkliban@redhat.com about 3 years ago

Problem: plugin PR builder uses older core RPMs

Solution: always install core from the latest GA build

closes #2751 https://pulp.plan.io/issues/2751

History

#1 Updated by amacdona@redhat.com over 3 years ago

  • Triaged changed from No to Yes

#2 Updated by mhrivnak about 3 years ago

  • Sprint/Milestone set to 39

#3 Updated by dkliban@redhat.com about 3 years ago

  • Description updated (diff)
  • Sprint/Milestone deleted (39)

#4 Updated by dkliban@redhat.com about 3 years ago

  • Sprint/Milestone set to 39

#5 Updated by dkliban@redhat.com about 3 years ago

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

#6 Updated by dkliban@redhat.com about 3 years ago

  • Description updated (diff)

#7 Updated by bmbouter about 3 years ago

For the latest version of core that will get installed, I'm wondering if that is the GA release of core or the nightly. Yesterday when we were talking I suggested using the nightly, but now I'm thinking that the existing GA is probably the best. The reason you would want it to be the nightly is because of situations wituations where plugin code relies on core changes that are not part of the GA release yet. The reason not to use nightlies is that they could be unreliable. I'm favoring using the GA for two reasons:

1. plugin code changes on the pulp2 line that also require unreleased core changes doesn't happen a whole lot (but some).

2. It's probably a best practice to test one thing at a time. This is about testing the plugin code, so that means core should be stable. If we use the nightly for most failures we'll have to determine if platform OR the plugin code is broken. By always using the GA of core we know everytime that it's the plugin. It's also possible that the plugin needs not-yet-released code in core, but the plugin writer should know if they are in one of those cases at which point tests can be run locally to prove they work perhaps.

What do others think about ^?

#8 Updated by dkliban@redhat.com about 3 years ago

  • Status changed from ASSIGNED to MODIFIED

Applied in changeset commit:32687f052864c7dfd736cbd7011635d31c7eac27.

#9 Updated by dkliban@redhat.com about 3 years ago

  • Description updated (diff)
  • Status changed from MODIFIED to ASSIGNED

I agree that it is best to test one change at a time. I updated the description based on this.

#10 Updated by dkliban@redhat.com about 3 years ago

  • Status changed from ASSIGNED to MODIFIED

#11 Updated by bmbouter about 3 years ago

  • Status changed from MODIFIED to NEW

We probably can't use the GA and need to use the nightlies for the rest of Pulp2 at least. I wrote some about why here[0].

Since we need to make a URLs change I'm moving back to NEW.

[0]: https://www.redhat.com/archives/pulp-dev/2017-June/msg00018.html

#12 Updated by mhrivnak about 3 years ago

  • Sprint/Milestone changed from 39 to 40

#13 Updated by bmbouter about 3 years ago

  • Description updated (diff)

I rewrote some based on pulp-dev discussion about how to better handle the case when a plugin requires unreleased core code.

#14 Updated by bmbouter about 3 years ago

  • Description updated (diff)

Updating to reflect the current state of completed work.

#15 Updated by dkliban@redhat.com about 3 years ago

  • Status changed from NEW to ASSIGNED

#16 Updated by mhrivnak about 3 years ago

  • Sprint/Milestone changed from 40 to 41

#17 Updated by mhrivnak about 3 years ago

  • Sprint/Milestone changed from 41 to 42

#18 Updated by mhrivnak almost 3 years ago

  • Sprint/Milestone changed from 42 to 43

#19 Updated by jortel@redhat.com almost 3 years ago

  • Sprint/Milestone changed from 43 to 44

#20 Updated by mhrivnak almost 3 years ago

  • Sprint/Milestone changed from 44 to 45

#21 Updated by jortel@redhat.com almost 3 years ago

  • Sprint/Milestone changed from 45 to 46

#22 Updated by mhrivnak almost 3 years ago

  • Sprint/Milestone changed from 46 to 47

#23 Updated by dalley over 2 years ago

  • Project changed from Packaging to Infrastructure

#24 Updated by rchan over 2 years ago

  • Sprint/Milestone changed from 47 to 48

#25 Updated by rchan over 2 years ago

  • Sprint/Milestone changed from 48 to 52

#26 Updated by rchan over 2 years ago

  • Sprint/Milestone changed from 52 to 53

#27 Updated by bmbouter over 2 years ago

  • Sprint/Milestone changed from 53 to 54

#28 Updated by rchan over 2 years ago

  • Sprint/Milestone changed from 54 to 56

#29 Updated by bmbouter over 2 years ago

  • Sprint set to Sprint 33

#30 Updated by bmbouter over 2 years ago

  • Sprint/Milestone deleted (56)

#31 Updated by bmbouter over 2 years ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes
  • Sprint deleted (Sprint 33)

Clearing out sprint 33. This work was deferred so it's going back to the sprint candidate list for next time.

#32 Updated by dkliban@redhat.com over 1 year ago

  • Status changed from ASSIGNED to NEW
  • Assignee deleted (dkliban@redhat.com)

#33 Updated by dkliban@redhat.com over 1 year ago

  • Groomed changed from Yes to No
  • Sprint Candidate changed from Yes to No

Please register to edit this issue

Also available in: Atom PDF