5cdbb047b2
To avoid wide breakage when a new release of neutron-lib is published, a trick can be exploited in order to catch the failures ahead of time. This patch documents the trick as conceived by dougwig's diabolical mind. Change-Id: I301ff9f945eeb1a90be63d6610f375627f077aa8
1.7 KiB
Releasing
Before you intend to release a new version of neutron-lib consider posting a sentinel patch that will allow to validate that the neutron-lib hash chosen for tagging is not breaking gate or check jobs affecting a project you care about, first and foremost Neutron.
As the patch shows, upper-constraints must be bypassed and that may itself lead to failures due to upstream package changes. The patch also shows (expected) Grenade failures in that Grenade pulls its own upper-constraints file during the upgrade phase. In general a newer version of neutron-lib is validated through the Tempest -full job (and Grenade runs a subset of it), so Grenade failures can be safely ignored.
In any other case consider (for failures caused by unpinned global requirements) hard-coding a dummy upper-constraints file that itself uses the specific neutron-lib hash you want to test. Furthermore, consider using a commit header that starts with DNM (Do Not Merge) to indicate that the change is just a test, or -2, if you have the right access permissions.
It is also worth noting that every Stadium project will have a periodic job running unit tests against the master version of neutron-lib (periodic-neutron-py34-with-neutron-lib-master being an example). Checking Grafana's periodic dashboard can give you a glimpse into the sanity of the integration between neutron-lib and the Stadium projects, and can be considered the quick check before going ahead with a full blown sentinel patch.