You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide RPM support for s390x platform as described in issue #3198 Is your feature request related to a problem? Please describe:
Add support for bazeldnf to maintain the rpm lists for s390x in BUILD.bazel
Describe the solution you'd like:
Add configurations necessary for bazeldnf to generate the rpm lists in WORKSPACE and BUILD.bazel, using the information for how to maintain these lists in .bazelrc, repo.yaml and hack/build/rpm-defs.sh as described in #3089 and #3090
Describe alternatives you've considered:
An alternative approach, which we've also been pursuing, would be to provide all the changes necessary for s390 builds in one PR; there are many moving parts to this, and the CI/CD needs to be installed on an s390x host to test the full set of changes.
Additional context:
Once the CI/CD system for s390x goes live, the full cross-compiled build for s390x CDI can, too.
The strategy we're choosing is to essentially cherry-pick changes that will run and be smoke tested in the x86-based CI/CD system, to reduce the risk when the PR for the full s390x build-and-test system is merged.
The text was updated successfully, but these errors were encountered:
make rpm-deps will conduct a smoke test -- that the additions do not break the build and produce the expected result: rpm list updates in the WORKSPACE file, now with rpms for s390x architecture!
Provide RPM support for s390x platform as described in issue #3198
Is your feature request related to a problem? Please describe:
Add support for bazeldnf to maintain the rpm lists for s390x in BUILD.bazel
Describe the solution you'd like:
Add configurations necessary for bazeldnf to generate the rpm lists in WORKSPACE and BUILD.bazel, using the information for how to maintain these lists in .bazelrc, repo.yaml and hack/build/rpm-defs.sh as described in #3089 and #3090
Describe alternatives you've considered:
An alternative approach, which we've also been pursuing, would be to provide all the changes necessary for s390 builds in one PR; there are many moving parts to this, and the CI/CD needs to be installed on an s390x host to test the full set of changes.
Additional context:
Once the CI/CD system for s390x goes live, the full cross-compiled build for s390x CDI can, too.
The strategy we're choosing is to essentially cherry-pick changes that will run and be smoke tested in the x86-based CI/CD system, to reduce the risk when the PR for the full s390x build-and-test system is merged.
The text was updated successfully, but these errors were encountered: