Re-resolve constraints for staged sources

[rabi]

Speculative builds stage unpinned patched sources but build against the committed upper-constraints snapshot, so any upstream min-requirement bump (e.g. heat oslo.versionedobjects>=3.12.0 vs pinned ===3.11.0) fails[1]. After staging, run tox -e update-sources per staged project: it keeps pre-existing src/ checkouts and their pins, re-fetches constraints in sync.

[1] https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/rdoproject.org/build/ce3ce1873a5749bfb139902d8cab1cc9

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign yazug for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rebtoor]

@rabi Thanks for tracking this down; the failure mode is real. Staging the Zuul checkout then building against the committed requirements.lock.<stream> is exactly why heat openstack-check dies (oslo.versionedobjects>=3.12.0 vs lock 3.11.0). SKIP_HASH_UPDATE and update-lockfiles cannot fix it: the former still uses the pinned constraints file if it already exists, and the latter pip-compiles from the old lock rather than staged src/*/requirements.txt.

I would rather not reuse update-sources for this, though. update_sources_file() keeps an existing src/ tree (good for the staged project) but still clones every missing sibling at branch tip and rewrites those hashes in sources.txt. Heat is lucky because upper-constraints + heat is the whole set. Horizon/tempest/neutron-server extras are not: an unstaged sibling would advance to origin/master for the image build even though the content provider never intended to test that pin.

update-lockfiles is the wrong direction too: it recompiles from the existing lock, so a staged requirements.txt lower-bound bump never gets in.

I put an alternative in #153: build.sh sync-locks / tox -e sync-locks. After staging it:

• refreshes upper-constraints.txt.<stream> from the stream branch tip, or from a Zuul openstack/requirements checkout when one is in the buildset (REQUIREMENTS_SRC)
• leaves staged src/ alone and clones missing siblings at the committed pin
• regenerates lockfiles from current src/*/requirements.txt (not from the old lock)
• does not rewrite sources.txt

Bootstrap is ensure-tox (already available via zuul-jobs) plus one tox -e sync-locks -- <projects> call, instead of a root venv and an unpinned pip install tox. Happy to close this PR in favor of that if it looks right, or fold any of this back here.

[rabi]

OK, I'll close this then.