On Wed, Aug 31, 2022 at 2:29 PM Ilya Maximets <[email protected]> wrote: > > On 8/25/22 14:52, David Marchand wrote: > > Debian packaging target builds OVS against a packaged DPDK version. > > As a result, it is not relevant in the dpdk-latest branch which follows > > DPDK development branch. > > > > Signed-off-by: David Marchand <[email protected]> > > --- > > .github/workflows/build-and-test.yml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/.github/workflows/build-and-test.yml > > b/.github/workflows/build-and-test.yml > > index 58ab85e5d7..b555f45024 100644 > > --- a/.github/workflows/build-and-test.yml > > +++ b/.github/workflows/build-and-test.yml > > @@ -198,6 +198,7 @@ jobs: > > path: config.log > > > > build-linux-deb: > > + if: ${{ github.ref != 'refs/heads/dpdk-latest' }} > > Hmm. This doesn't seem to work for the robot as it doesn't use the > 'dpdk-latest' as a branch name. Maybe we should define the DPDK_VER > variable globally and check it instead?
Indeed, filtering on branch name is not enough for patches submitted against dpdk-latest branch. We discussed this offlist. For others, here is a summary of what I tried. I tried to define DPDK_VER as a global env variable. But filtering on this env does not work: I get non-obvious errors from gha yml checker. After reading the documentation, I understand that a job level if can't use global env: context. https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability "jobs.<job_id>.if" is marked as only supporting github, needs, inputs contexts. Funnily, "jobs.<job_id>.steps.if" can use env context, but marking all steps with this is really ugly as a job is started for nothing. Since the "needs" context is supported, I tried to build a pipeline: - added a "dummy" job outputs the global env variable, - then, the debian packaging jobs were made dependent on this dummy job, and the if: keyword used the output of the env variable, This works, but we start a job simply to cover a limitation in GHA. This is ugly. On the other hand, the dpdk-latest already has a patch to select which DPDK version to build against. So when dpdk-latest will be rebased on current master, the simpler is to update this patch and put a if: false in front of the debian packaging jobs as part of the change. > > > BTW, not a problem of this patch, but I spotted this: > > - compiler: gcc > dpdk_shared: dpdk_experimental > > While it should be: > > - compiler: gcc > dpdk_experimental: yes > > Otherwise, I don't think we're testing experimental APIs. Mm, good catch. That is really strange as I remember fixing and testing this stuff... I'll look at it. I think the simpler is to send rebased patches for dpdk-latest. Ian, are you ok with it? -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
