On 11/15/23 12:02, Ilya Maximets wrote:
On 11/15/23 17:00, Dumitru Ceara wrote:
All of the above were changed to track the latest available releases.
Initially that seemed like a good idea but in practice, a new release would
potentially (silently) cause CI runs that used to pass on given stable
versions to unexpectedly start failing.
To address that this series pins all versions we can control allowing us
to use different values for different branches.
NOTE: the last commit of this series will look slightly different on
stable branches, e.g., on branches <= 23.06 we need Python <= 3.11 and
Fedora 37.
The first commit of the series bumps the OVS submodule to include the
latest fixes to errors reported by recent versions of flake8.
Changes in v2:
- added first patch to bump OVS submodule
- addressed Ales' review comments:
- moved the logic to determine which image to use out of ci.sh;
it's now in the workflow itself.
- moved setting of OVN_IMAGE in the same block with all related
env vars
- added a note for maintainers in the release process documentation
to mention that the new workflow will likely have to be triggered
manually (at least once) when branching for a new release. GitHub
doesn't allow periodic jobs on non-default branches.
IMHO, that sounds horrible to maintain. Can we just build things per run?
What if we set up the "Containers" action to run on branch creation?
Would that adequately substitute for the manual run that creates the image?
If we only have to run the action once each time a branch is created, I
don't think that qualifies as "horrible" to maintain. This could be
lumped into our branch creation scripts. However, if it can be automated
as I suggested above, that would be better.
How much value these containers actually have?
As patch 2 mentions, it allows for us to use different distro bases for
each version. But I also think that having the container image cached
allows for quicker test runs since we are not having to reconstruct the
environment each time we perform test runs.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
