Dpdk 26.07 on cicd desgin - #1693
Open
DawidWesierski4 wants to merge 36 commits into
Open
Conversation
Five failures of the same kind: the build asserting something about its
environment instead of asking it.
- The rocky9 image reported "libxdp is absent after install" from a successful
install. xdp-tools and libbpf default LIBDIR to ${PREFIX}/lib64, which Debian's
pkg-config does not search and which does not exist on RHEL, so neither default
is portable and the multiarch directory libbpf was pinned to by hand only moved
the problem. Asking `pkg-config --variable pc_path` does not answer it either:
on Rocky 9 that is a string from a .pc file the distribution ships, and it omits
the compiled-in /usr/local/lib64/pkgconfig. So plant a probe .pc in each
candidate under the prefix and install into one pkg-config actually reads, and
register it with the dynamic linker, whose default path is just as
distribution-specific and which fails at load time rather than at link time.
- With libxdp visible, meson enables the manager's XDP target and clang stops on
gnu/stubs-32.h, which no package in the rocky9 image provides. The Ubuntu images
install gcc-multilib for this; glibc-devel.i686 is the RHEL counterpart.
- -flarge-source-files is gcc's, and clang rejects unknown -f arguments outright,
so every RxTxApp translation unit failed once the fuzz leg built with clang. It
is now offered to the compiler and used only if taken, like -msse4.2 above it.
- The fuzz targets link against GPU direct, which their sources call: the wrappers
#include the library sources they exercise, so those callees have to be on the
fuzz link line and not only on libmtl's. tests/unit carries the same conditional.
The assertion that started this was worth keeping: without it the image built
green with pkg-config reporting libxdp absent, which does not fail a build -- it
configures MTL without AF_XDP.
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
gcc builds these; clang's -Werror does not, so the fuzz leg -- which has to use clang for libFuzzer -- stopped in the test build: - st40p_handler.cpp carried a constant nothing reads; - st40i_tests.cpp captured a compile-time constant into a lambda that does not need it captured; - St30pRedundantLatency stored a latency and a starting time it never read. The constructor body looked like it used one of them, but it assigned to its own parameter, not to the inherited startingTime -- and initializeTiming(), which every caller runs straight after construction, sets that member anyway. So nothing observable changes. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Every access to these counters already goes through C11 atomics -- the tasklet adds to them, st*p_*_get_session_stats() reads them from another thread -- but the fields themselves were plain uint64_t. gcc's atomic builtins accept that; clang does not, so the library did not compile with clang at all, which is how it stayed unnoticed. Same codegen under gcc, because gcc was already emitting atomic operations. The USDT probes are the other half: their argument macros do arithmetic on what they are handed, and clang refuses that on an _Atomic operand, so the three sites that passed framebuff->stat now read it out first. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Auto pacing selection picks rl on any driver whose rl_type is TM, and then treats the two ways that choice can fail differently: a queue whose rate limit will not set falls back to tsc with a warning, while a tm hierarchy that will not build fails mtl_init outright. Both mean the same thing -- the driver in front of us has no rate limiter to offer -- and in auto mode neither is the user's choice to defend, so both should degrade the same way. Found while looking at an E830 whose PF grants its VF no QoS capability. That host crashes inside the iavf PMD before returning, so this does not rescue it; what it fixes is the case where a driver reports the missing capability properly, which today is a refusal to start rather than a session paced by tsc. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The workflows implemented themselves. Host setup, cache decisions, driver builds, test invocation and report collection were multi-line `run:` programs inside YAML, which meant no operation could be run, read or tested anywhere except on a runner, by pushing. Debugging a bare-metal job took a push and a forty-minute wait for a forty-megabyte log. Every operation is now a focused script under `.github/scripts/ci/`, verb-style and runnable by hand, with `Taskfile.yml` as the single entry point both the workflows and a developer call. The YAML orchestrates; it does not compute. `check-yaml-policy.sh` keeps it that way, and also rejects a third-party action that is not pinned to an immutable SHA. Three contracts the scripts encode, each one a failure this fleet actually had: **Jobs verify host state; they never install it.** apt packages, kernel modules, DMA bindings, the media share, the analyser -- a job that repairs what it finds hides drift in the host image and races every other job on the machine. So each check fails in seconds with the one command that fixes it, on the host that needs it. `configure-host.sh`, `media-assets.sh`, `ebu-list.sh` and `ice-required.sh` are that contract; a missing analyser is degraded mode rather than failure, because absence is not misconfiguration, and `MTL_CI_REQUIRE_COMPLIANCE=1` makes it fatal again on a host that has one. Lab facts come from `/etc/mtl-ci/runner.env` on the host that owns the hardware, not from GitHub secrets, which are a second copy of lab configuration kept in sync by hand. **A cache hit has to be usable, not merely present.** `actions/cache` saves in a post step that runs whether the job passed or not, so a run that died half-way through installing MTL stores the half-written tree under an unchanged key, and every later run restores it, skips the build and fails in the first consumer that resolves `mtl.pc`. The keys are content-addressed with an explicit schema (`cache-keys.sh`, `cache-schema.env`) so a fixed layout bug can be rotated past, entries are immutable, and `validate-cache.sh`, `validate-ice.sh`, `validate-jpegxs.sh` and `validate-dependencies.sh` reject a hit that cannot be used -- including an ICE module whose vermagic, kernel ABI fingerprint, compiler identity or Kahawai QoS capability does not match the host it is about to load on. **The acceptance virtualenv is a cache, not host state.** It is built from `requirements.txt` in the checkout, lives in the runner user's cache outside anything `git clean` touches, and is the same for every job on the host. So it is created once, rebuilt when the requirements change or when the host's python moves under it, built with `python3 -m venv`, `virtualenv` or `uv` -- whichever the host has, since none of them installs anything -- and names `python3-venv` when the host has none. `watch-run.sh` is the developer's side of the same layer: it resolves a commit from `--run/--pr/--sha/--branch`, defaulting to the pushed tip so it cannot report on a commit that only exists locally, distinguishes "queued, no runner yet" from a failure, and ends with the job, the failed step and the error lines. Twenty lines instead of the log. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The YAML now only orchestrates: each step names a `task ci:*` entry point, so the same command runs in a job and on a developer's machine. What is left in the workflows is the part that is genuinely about GitHub -- what triggers, what runs where, what may run at once, and what a queue is allowed to cost. - **A shared fleet is the scheduling problem.** Every NIC label is served by one host, so a second job at a label is a queue and not throughput. Superseded Build, smoke, base and docker runs are cancelled before they queue, and `pr-gate.yml` states its wait as a queue budget rather than a flat twenty minutes -- a build that has not started yet is not a build that is failing. When the budget does expire, the gate says it gave up because no runner came, which is a different thing from a failed build and used to look identical. - **A bare-metal job has to be bounded at every level.** Job timeout, run timeout and per-suite caps, so a hung test releases the host instead of holding a card for hours; `gtest-bare-metal.yml` carries the bounds the local harness asserts. - **The smoke matrix says what each leg is for.** The `i225` leg runs the low-bandwidth subset with no capture device and its own timeouts, because that card has no SR-IOV and two PFs rather than VFs; it is `optional` while the label is new. A leg with `no_capture` skips the analyser check it cannot use. - **`provision-runner.yml` is dispatch-only**, the single deliberate exception to "jobs install nothing": a human asks for a host to be prepared, by name. - Privileged bare-metal steps no longer open with a trace-fd error, the acceptance report the non-smoke suites write in place is left alone, and a host running an ICE driver that is not the one the suite needs is told so before it tests. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
A change to a bare-metal job could only be tested by pushing it and waiting for a runner that might be busy for hours. `run-job.sh` runs the same job here -- `--runner docker` for anything that does not need a card, `--runner host` on a machine that has one -- through the same Taskfile entry points the workflow calls, with a local cache store that reproduces `actions/cache` semantics including its immutability. That is what proved the `i225` leg before CI ever dispatched it: two runs on a host with an I225-LM, `11 passed, 3 skipped` in about twenty-two minutes, while the leg itself was still queued behind a label nothing advertised. `tests/` holds the assertions about all of this that do not need hardware: cache schema rotation and poisoning, the gtest bounds, the wait-for-workflow script, the YAML migration, the virtualenv builders, and that a missing compliance analyser is not a gate. `task ci:test-dependencies` runs them, and so does the build workflow. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The loop an agent runs on CI is: push, find the run, find the failing job, find the failing step, find the error in a forty-megabyte log. The first four steps are mechanical and the last is a needle in ANSI-coded output, so all five became tools: `ci_pr_checks` and `ci_pr_failures` for what a pull request's checks say, `ci_last_log` for the interesting lines of one, and `ci_watch_run(pr=…)`, which blocks until the runs of a commit finish and then names the job, the step and the error line. The other half drives the local harness rather than reading GitHub -- `ci_list_jobs`, `ci_run_job`, `ci_test_pr`, `ci_list_tasks`, `ci_run_task`, `ci_cache_status`, `ci_check_ebpf`, `ci_diagnostics` -- so the same agent can reproduce a leg here instead of queueing behind the fleet. Failure counts and captured stderr are bounded, so a broken job cannot flood a context window; the repository argument is validated before anything is spawned; and the watcher's subprocess is given two minutes beyond its own poll deadline, so it reports the timeout itself instead of being killed while writing it. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The four agents each own a phase and nothing owned the sequence: which of them takes the next task, and which tasks may run at the same time. That decision was made ad hoc, once per session, and it is where this repository's own facts matter more than general judgement. So the orchestrator is the only agent permitted to invoke the others, and its parallel-safety test is five mutexes that are real here: a file, the build tree and acceptance virtualenv, a physical host with its hugepages and VF layout, a NIC label -- one host per label, so a second job at one is a queue and not throughput -- and the gate chain of a single change. It dispatches, records evidence and never implements: its edit tool is for the task board and its shell is for observation. Evidence is named per dispatch, including a non-empty `runner_name` for a CI job, which is the distinction the i225 analysis turned on. The `mtl-cicd` skill is the CI half of the routing matrix, which had no agent: the design contract that workflows orchestrate and scripts implement, and the inventory to read before editing either. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Resolve the datapath from the ports under test instead of hardcoding it, register the JPEG XS plugin tree, capture ST 2110 pcaps under sudo so compliance checks get complete captures, make room before recording raw video and delete the RX recording once it has been checked. Generated configs and the low-bandwidth cases are adjusted for the i225 smoke leg. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Three things a person needs and could previously only get by reading the workflows: what the pipeline is (`cicd_setup_proposition.md`, with the prebuilt dependency problem it solves in `.github/github_actions_issue.md`), what a runner has to have before it can serve a label (`ci_runner_setup.md` -- the packages the jobs check but cannot fix, the media share, the EBU LIST analyser and when its absence is degraded mode rather than failure, and which host carries which card), and why the `i225` leg was red for two days without ever running (`i225_leg_analysis.md`). That last one is here because the evidence is not visible in the Actions UI. A job queued because the fleet is busy and a job queued because no host advertises its label are the same grey dot; they differ only in `runner_name`, and every i225 job record had an empty one until mtl-runner-12 came online. The one real failure after that took twelve seconds and named its own fix. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The local harness, its cache store and the reports the jobs collect all land in the checkout, and `git status` has to stay readable for the suites that assert on it. CODEOWNERS gains the CI directories, which had no owner. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Three lint systems disagreed. format-coding.sh invoked clang-format, shfmt
and the Python tools directly and required each on PATH, so the version a
developer happened to have installed decided the result; linter.yml ran
super-linter against a second set of rule files; neither pinned the same
versions as the other.
.pre-commit-config.yaml is now the only place a tool, a version, an
argument or a file filter is declared. checkpatch.sh chooses which files
to feed it and how to report, format-coding.sh is its write-mode wrapper,
and the git hooks and linter.yml run that same list on Linux, macOS and
Windows. super-linter keeps only what the list cannot reproduce, including
GITLEAKS: its hook scans the staged diff and so cannot scan a whole tree
or a pull request.
.clang-format becomes a real file at the repository root because
clang-format searches upward from each source file, and a Windows checkout
without symlink support materializes a symlink as a text file, at which
point it silently falls back to LLVM style.
Every pin is at its latest release, and each was measured on its own with
the rest of the config held fixed:
clang-format 14.0.6 -> 22.1.8 isort 5.13.2 -> 8.0.1
black 24.4.0 -> 26.5.1 flake8 7.0.0 -> 7.3.0
ruff 0.4.1 -> 0.16.3 shfmt 3.7.0 -> 3.13.1
shellcheck 0.10.0 -> 0.11.0 markdownlint 0.43.0 -> 0.49.1
yamllint 1.35.1 -> 1.38.0 actionlint 1.7.7 -> 1.7.12
gitleaks 8.16.3 -> 8.30.0 textlint 14.0.4 -> 15.8.0
htmlhint 1.1.4 -> 1.9.2 pre-commit-hooks 6.0.0 (new)
Nine of those are byte-identical over the whole tree. Four are not, and
the interesting content of this commit is what was done about them.
**A version bump may not smuggle in a rule change.** Three tried:
ruff 0.16 reported 592 findings on a tree ruff 0.4 passed -- blind
excepts, datetime timezones, pyupgrade rewrites. None of it was new code.
ruff's *implicit* default rule set grew from about 40 rules to 413, and
.ruff.toml named no rules, so it pinned the version rather than the check.
It now selects E, W and F explicitly.
markdownlint 0.49 ships MD059 and MD060, which did not exist when this
config was vendored; MD060 alone reports 309 findings and rewrites 20
files. Both are off, with the reason recorded at the key.
textlint-rule-terminology 5.x rewrote prose in 15 files, including 18
lines of published CHANGELOG.md history, and replaced "blank line" with
"empty line" -- in a document describing git commit format, where "blank
line" is git's own wording. The *engine* is bumped to textlint 15.8.0; the
*word list* stays at terminology 4.0.1, because a word list is rule
content and rule content is versioned separately for exactly this reason.
clang-format 22 changed two things. It no longer reads `(type)-1` as a
cast, so `((mtl_iova_t)-1)` becomes `((mtl_iova_t) - 1)`; that is
whitespace, the tokens are identical, and for `((align)-1)` -- a macro
parameter, not a type -- the new spacing is simply correct. Accepted. But
from 18 on it also breaks a braced initializer whose elements carry
trailing comments to one element per line, which added 480 lines to
st_avx512_vbmi.c and destroyed the layout of six permute tables that are
written one pixel group per row so the pattern can be read against the
422le10 packing they implement. Those six now sit in a
`/* clang-format off */` region: a pin on the layout, not an exemption
from review.
flake8 is kept rather than folded into ruff, for one measured reason:
ruff 0.16 does not implement F824 ("dead `global` declaration") at all --
`ruff rule F824` answers "unknown rule". flake8 7.3 found two, both
genuinely dead (the names are only mutated, never rebound), both removed
here. .ruff.toml mirrors flake8's rule set rather than extending it so
that retiring flake8 later is a delete and not a re-measurement.
black's `--line-length 88` is black's own default, written down because
the documented Python line length was 120 while the formatter had been
wrapping at 88 the whole time. Not a conflict -- black wraps at 88, ruff
only rejects past 120 -- but only one of the two was stated, and a default
is not a pin.
Five pre-commit-hooks guards are added. None is a style check; each
mechanically enforces a claim this repository already makes and nothing
checked: destroyed-symlinks (the .clang-format-as-text failure above),
check-illegal-windows-names and mixed-line-ending (the platform support
claim), check-merge-conflict, and detect-private-key -- the only secret
scan that runs in a bare whole-tree checkpatch.sh, since gitleaks sees
only the staged diff.
Four more from that repo were probed and left off, two because they fail
on pre-existing defects that are not this commit's to fix, both now
recorded in doc/coding_standard.md §3.1:
check-json 20+ tests/tools/RxTxApp/script/**/*.json use
trailing commas; json-c accepts them, strict JSON
does not.
check-case-conflict tests/acceptance/mtl_engine/RxTxApp.py and
rxtxapp.py are both tracked, so this tree cannot be
checked out on a case-insensitive filesystem --
which contradicts the macOS and Windows support
claimed above. Renaming a module mtl_engine imports
is not a lint change.
The remaining source churn is clang-format 22 and black 26 improving what
they touch: `struct st40_meta m {}` becomes `m{}`, single-expression
lambdas collapse, and black hugs a sole `textwrap.dedent` argument.
check-illegal-windows-names earned its place immediately. patches/ was
excluded globally -- a vendored patch series must not be reformatted -- and
a global exclude turned out to be wrong in both directions. It protected
nothing, because every formatter here is selected by language type and a
*.patch file is none of those types; deleting it changed no hook's result
over the whole tree. And a hook-level exclude cannot un-exclude a global
one, so it silently disabled the one hook that reads paths instead of
content. Blinded, that hook reported "no files to check" while
patches/dpdk/26.03/0012-net-ice-e830:-use-direct-MMIO-for-PHC-update.patch
sat in the tree. A colon is not a legal filename character on Windows, so
`git checkout` there refuses the whole clone with "error: invalid path"
and exit 128 -- meaning the Windows support claimed in §6 had been broken
for as long as that file existed, and the new Windows CI job could never
have gone green no matter what the linters said. The file is renamed
(nothing references it by name; script/build_dpdk.sh globs *.patch and the
0012- ordering prefix is preserved), the exclusion now sits only on
mixed-line-ending, the one hook that does read every file regardless of
type, and the guard is what keeps the name legal from here on.
Renaming the CI job broke build.yml's linter gate, so that is fixed here too.
wait-for-linter polled for super-linter's check run, "Lint Code Base",
which stopped existing the moment checkpatch replaced it. A missing check
is not a failure in that action, it is a wait, so every pull request spent
ten minutes timing out and reported infrastructure flake rather than a
configuration error. The gate now names all four check runs that linter.yml
actually produces -- the three checkpatch OSes and the residual job -- and
build still declares needs: [wait-for-linter, checksums], so a lint failure
skips the DPDK build instead of paying for it. wait-for-workflow takes a
newline-separated list and requires every entry to reach success; a single
name is unchanged, which is what the other two callers pass.
The coupling is by check-run name and nothing validates the two lists
against each other, so all three files now say so at the point where the
mistake would be made: both linter.yml job names, the gate itself, and
doc/coding_standard.md §4.1. The action also reads its inputs from env
instead of interpolating them into the script body, which a multi-line
value would have broken outright.
18 hooks, ./checkpatch.sh clean and idempotent, ColumnLimit stays 90.
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Three lint systems disagreed. format-coding.sh invoked clang-format, shfmt
and the Python tools directly and required each on PATH, so the version a
developer happened to have installed decided the result; linter.yml ran
super-linter against a second set of rule files; neither pinned the same
versions as the other.
.pre-commit-config.yaml is now the only place a tool, a version, an
argument or a file filter is declared. checkpatch.sh chooses which files
to feed it and how to report, format-coding.sh is its write-mode wrapper,
and the git hooks and linter.yml run that same list on Linux, macOS and
Windows. super-linter keeps only what the list cannot reproduce, including
GITLEAKS: its hook scans the staged diff and so cannot scan a whole tree
or a pull request.
.clang-format becomes a real file at the repository root because
clang-format searches upward from each source file, and a Windows checkout
without symlink support materializes a symlink as a text file, at which
point it silently falls back to LLVM style.
Every pin is at its latest release, and each was measured on its own with
the rest of the config held fixed:
clang-format 14.0.6 -> 22.1.8 isort 5.13.2 -> 8.0.1
black 24.4.0 -> 26.5.1 flake8 7.0.0 -> 7.3.0
ruff 0.4.1 -> 0.16.3 shfmt 3.7.0 -> 3.13.1
shellcheck 0.10.0 -> 0.11.0 markdownlint 0.43.0 -> 0.49.1
yamllint 1.35.1 -> 1.38.0 actionlint 1.7.7 -> 1.7.12
gitleaks 8.16.3 -> 8.30.0 textlint 14.0.4 -> 15.8.0
htmlhint 1.1.4 -> 1.9.2 pre-commit-hooks 6.0.0 (new)
Nine of those are byte-identical over the whole tree. Four are not, and
the interesting content of this commit is what was done about them.
**A version bump may not smuggle in a rule change.** Three tried:
ruff 0.16 reported 592 findings on a tree ruff 0.4 passed -- blind
excepts, datetime timezones, pyupgrade rewrites. None of it was new code.
ruff's *implicit* default rule set grew from about 40 rules to 413, and
.ruff.toml named no rules, so it pinned the version rather than the check.
It now selects E, W and F explicitly.
markdownlint 0.49 ships MD059 and MD060, which did not exist when this
config was vendored; MD060 alone reports 309 findings and rewrites 20
files. Both are off, with the reason recorded at the key.
textlint-rule-terminology 5.x rewrote prose in 15 files, including 18
lines of published CHANGELOG.md history, and replaced "blank line" with
"empty line" -- in a document describing git commit format, where "blank
line" is git's own wording. The *engine* is bumped to textlint 15.8.0; the
*word list* stays at terminology 4.0.1, because a word list is rule
content and rule content is versioned separately for exactly this reason.
clang-format 22 changed two things. It no longer reads `(type)-1` as a
cast, so `((mtl_iova_t)-1)` becomes `((mtl_iova_t) - 1)`; that is
whitespace, the tokens are identical, and for `((align)-1)` -- a macro
parameter, not a type -- the new spacing is simply correct. Accepted. But
from 18 on it also breaks a braced initializer whose elements carry
trailing comments to one element per line, which added 480 lines to
st_avx512_vbmi.c and destroyed the layout of six permute tables that are
written one pixel group per row so the pattern can be read against the
422le10 packing they implement. Those six now sit in a
`/* clang-format off */` region: a pin on the layout, not an exemption
from review.
flake8 is kept rather than folded into ruff, for one measured reason:
ruff 0.16 does not implement F824 ("dead `global` declaration") at all --
`ruff rule F824` answers "unknown rule". flake8 7.3 found two, both
genuinely dead (the names are only mutated, never rebound), both removed
here. .ruff.toml mirrors flake8's rule set rather than extending it so
that retiring flake8 later is a delete and not a re-measurement.
black's `--line-length 88` is black's own default, written down because
the documented Python line length was 120 while the formatter had been
wrapping at 88 the whole time. Not a conflict -- black wraps at 88, ruff
only rejects past 120 -- but only one of the two was stated, and a default
is not a pin.
Five pre-commit-hooks guards are added. None is a style check; each
mechanically enforces a claim this repository already makes and nothing
checked: destroyed-symlinks (the .clang-format-as-text failure above),
check-illegal-windows-names and mixed-line-ending (the platform support
claim), check-merge-conflict, and detect-private-key -- the only secret
scan that runs in a bare whole-tree checkpatch.sh, since gitleaks sees
only the staged diff.
Four more from that repo were probed and left off, two because they fail
on pre-existing defects that are not this commit's to fix, both now
recorded in doc/coding_standard.md §3.1:
check-json 20+ tests/tools/RxTxApp/script/**/*.json use
trailing commas; json-c accepts them, strict JSON
does not.
check-case-conflict tests/acceptance/mtl_engine/RxTxApp.py and
rxtxapp.py are both tracked, so this tree cannot be
checked out on a case-insensitive filesystem --
which contradicts the macOS and Windows support
claimed above. Renaming a module mtl_engine imports
is not a lint change.
The remaining source churn is clang-format 22 and black 26 improving what
they touch: `struct st40_meta m {}` becomes `m{}`, single-expression
lambdas collapse, and black hugs a sole `textwrap.dedent` argument.
check-illegal-windows-names earned its place immediately. patches/ was
excluded globally -- a vendored patch series must not be reformatted -- and
a global exclude turned out to be wrong in both directions. It protected
nothing, because every formatter here is selected by language type and a
*.patch file is none of those types; deleting it changed no hook's result
over the whole tree. And a hook-level exclude cannot un-exclude a global
one, so it silently disabled the one hook that reads paths instead of
content. Blinded, that hook reported "no files to check" while
patches/dpdk/26.03/0012-net-ice-e830:-use-direct-MMIO-for-PHC-update.patch
sat in the tree. A colon is not a legal filename character on Windows, so
`git checkout` there refuses the whole clone with "error: invalid path"
and exit 128 -- meaning the Windows support claimed in §6 had been broken
for as long as that file existed, and the new Windows CI job could never
have gone green no matter what the linters said. The file is renamed
(nothing references it by name; script/build_dpdk.sh globs *.patch and the
0012- ordering prefix is preserved), the exclusion now sits only on
mixed-line-ending, the one hook that does read every file regardless of
type, and the guard is what keeps the name legal from here on.
Renaming the CI job broke build.yml's linter gate, so that is fixed here too.
wait-for-linter polled for super-linter's check run, "Lint Code Base",
which stopped existing the moment checkpatch replaced it. A missing check
is not a failure in that action, it is a wait, so every pull request spent
ten minutes timing out and reported infrastructure flake rather than a
configuration error. The gate now names all four check runs that linter.yml
actually produces -- the three checkpatch OSes and the residual job -- and
build still declares needs: [wait-for-linter, checksums], so a lint failure
skips the DPDK build instead of paying for it. wait-for-workflow takes a
newline-separated list and requires every entry to reach success; a single
name is unchanged, which is what the other two callers pass.
The coupling is by check-run name and nothing validates the two lists
against each other, so all three files now say so at the point where the
mistake would be made: both linter.yml job names, the gate itself, and
doc/coding_standard.md §4.1. The action also reads its inputs from env
instead of interpolating them into the script body, which a multi-line
value would have broken outright.
18 hooks, ./checkpatch.sh clean and idempotent, ColumnLimit stays 90.
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The bare `"terminology": true` form loads the default term list, whose `png` -> `PNG` rule has no word-boundary guard on the left. It rewrote `rte_pcapng_copy`, `*.png` paths, and every other identifier ending in `png`. The explicit rule keeps the default list and excludes a `png` preceded by a dot or by `pca`. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
MTL sends nothing to dev@dpdk.org any more. The plan is a version bump: move to DPDK 26.07, drop the 5 patches 26.07 already carries, keep and renumber the 11 it does not, and add a test at the cheapest tier for each change that can alter behaviour. upstreaming.md keeps the review history only as the evidence for the drop list, and now links every claim to the file it rests on. Three findings correct the earlier record: - The 2 KB scheduler burst also comes from the kernel ICE patch, which is what programs a VF rate limiter. Dropping the DPDK-side patch may change nothing in the normal deployment, so the rl_burst_size devarg needs a measurement before any code. - The accepted pcapng change is not in 26.07, so mt_pcap.c does not break on this bump. - /home/labrat/dev1/dpdk no longer exists. Six upstream commit hashes rest on it and are a record, not a measurement; T-01 re-proves them against the v26.07 source. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The orchestrator owns the work list in tasks.md and fires Gates 5 and 6, which mtl-developer can only name. It has no Copilot counterpart in .github/agents/, so the developer and planner prompts said "the user" where the invoker may now be an agent; both are corrected to name the invoker instead. mtl-ste-writing is a symlink into .github/skills/, like every other skill, so Copilot and Claude Code share one copy. CLAUDE.md now points at tasks.md and upstreaming.md, so a fresh session finds the active plan without being told where it is. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
requirements.txt read `mcp[cli]>=1.0.0`, which resolved to mcp 2.0.0. That
release removed `mcp.server.fastmcp`, which both mtl_mcp_server.py and
mtl_acceptance_mcp_server.py import, so each server died with
ModuleNotFoundError before any handshake and every mtl-system-setup and
mtl-acceptance-setup tool went missing from the agent inventory. The venv now
rebuilds at 1.29.0, the last 1.x release, and a hand-fed stdio handshake lists
32 tools on one server and 7 on the other.
The pin alone does not heal a venv that already holds 2.x. The old guard
`if ! python3 -c "import mcp"` succeeds there, so pip never ran and the new
ceiling never applied. Both wrappers now probe
`importlib.util.find_spec("mcp.server.fastmcp")` — the module the servers
really import — so a 2.x venv reinstalls itself and no host needs to delete
.github/mcp/.venv by hand.
A floating major version in agent tooling fails silently and looks like a
broken agent, which is the part worth remembering.
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
versions.env is the single pin, and 4 places named a version beside it.
doc/build.md, doc/build_WIN.md and doc/experimental/header_split.md hardcoded
25.11 or 23.03 in a git checkout, a patch glob or both, so a bump left the
instructions pointing at a directory the tree no longer has. Each file now
sources versions.env and uses ${DPDK_VER}.
validation-tests.yml set DPDK_VERSION: '25.11' in env and used it in the DPDK
checkout. It now reads versions.env into GITHUB_ENV instead. The step is
unreachable today, because DPDK_REBUILD is hardcoded 'false' and is not a
dispatch input, so all 4 consumers never run; this fixes a latent defect, not
a live one. T-17 owns the reachability question.
Two version literals stay on purpose. doc/design.md keeps 25.11 as the
Ubuntu 22.04 AF_XDP workaround, which the file already justifies, and
.github/workflows/msys2_build.yml keeps [25.03, 23.11], because bumping that
matrix would answer a product question in silence. T-13 owns it.
header_split.md no longer says DPDK v23.03 "is verified" as though the reader
should stay there. It says the feature is experimental, states how to
reproduce the verified configuration, and says to restore the pin afterwards.
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The 26.07 set is 11 files: 9 flat patches, plus hdr_split/0001 and windows/0001. It is a copy of patches/dpdk/26.03/, not a move — D5 keeps the 26.03 directory for the maint branches and for a rollback. Five patches are dropped, because the v26.07 source proves the change is already there: the iavf ring-descriptor cap, the inverted iavf_tm guard, the virtchnl queue-vector size, the E830 PHY model test, and the scheduler burst size. The last one is not covered in the ordinary sense. Upstream superseded MTL's approach with an rl_burst_size devarg and did not take MTL's change, so 26.07 still reads ICE_SCHED_DFLT_BURST_SIZE (15 * 1024) and the old patch still applies. It is dropped because the devarg replaces it; the replacement lands in lib/ as an mtl_port_init_params field. Renumbering is 26.03 0004 to 0013 into 26.07 0001 to 0009. script/build_dpdk.sh applies a flat *.patch glob, so name order is apply order, and the two subdirectories are applied by hand. The directory is inert until versions.env moves. That file still pins DPDK_VER=26.03, and the glob is patches/dpdk/"$DPDK_VER"/*.patch, so nothing reaches these files and no running test can change behaviour because of them. The patch metadata was repaired in the same pass. Every header-bearing file reads `From nobody Mon Sep 17 00:00:00 2001` on line 1, in place of hashes that were a keyboard walk, a hand-typed counter and 40 zeros. Fabricated [PATCH nn/mm] series counters are now a bare [PATCH]. Comma-form identities, which DPDK's own devtools/check-git-log.sh rejects against .mailmap, are plain. Cc: stable@dpdk.org is gone, because this tree posts nothing. Eight of the 9 flat patches commit under 5 real author names. 0009 commits as `MTL Contributor <noreply@example.com>`, and that is deliberate: 5 independent routes failed to recover its author, and inventing a better guess is not a fix. Its Signed-off-by: keeps the same placeholder, because a real name there would forge a DCO certification and deleting the trailer would edit the body. T-27 and T-31 own what is left. The index <pre>..<post> lines are not maintained — 13 stale lines in 7 of the 11 files. Repairing them means regenerating bodies, which a metadata pass must not do. Plain patch -p1 and plain git am ignore them, so the cost lands only on a future git am -3. T-21 owns it. Verified against a pristine v26.07 tree: the 9 flat patches git am clean in order with 0 fuzz and 0 rejects, each optional patch applies after those 9, and VERSION ends 26.07.0_mtl_. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
DPDK 26.07 replaces the MTL patch that flipped ICE_SCHED_DFLT_BURST_SIZE from 15 KB to 2 KB with an ice devarg, rl_burst_size. Dropping that patch is not a no-op for MTL: st_tx_video_session.c:580 already compensates VRX for a 2 KB burst, and MTL selects rate-limit pacing on an ice PF with no PF or VF test, so a PF port would run against a 15 KB burst the pacing does not expect. The new field lets a caller ask for the old value. dev_build_pci_devarg() appends ",rl_burst_size=%u" to the BDF for the PCI path only. Zero means unset and builds a bare BDF, which is the safe default. The field is opt-in because it must be. iavf_parse_devargs() passes a valid-key list to rte_kvargs_parse, so one unknown key returns NULL and the VF never probes; ice uses a valid-key list too, so a misspelling breaks the PF probe as well. No silent no-op is possible either way. MTL cannot tell a PF from a VF before rte_eal_init(), so the library cannot make the choice for the caller — mt_user_params_check() only warns when the field is set on a PMD that has no devarg path at all. MTL does not validate the range. lib/meson.build accepts libdpdk >= 25.03, so one binary can link against ice versions with different bounds and a copied constant would drift toward MTL rejecting a value the driver accepts. The ice PMD stays the single source of truth and its failure is loud, -EINVAL from the probe. No ABI break. The field takes 4 bytes of tail padding that uint64_t flags plus int socket_id already forced, so sizeof stays 16 and no member of port_params[MTL_PORT_MAX] moves. The Rust example still needs 1 line, because a #[repr(C)] struct literal is exhaustive whatever the layout does. The residual hazard belongs to the header, not here: a caller compiled against the old header leaves those bytes uninitialized, so a caller that does not zero the whole struct can fail the probe on garbage. A doc comment cannot fix that, since the caller at risk never reads the new header; a size or version field can, and that is a separate change. MT_EAL_PORT_ARG_MAX_LEN replaces 4 open-coded 2 * MTL_PORT_MAX_LEN widths with one named constant, and every write now takes sizeof(port_params[i]) from the row declaration. Worst cases against 128 bytes are 109 for eth_af_packet, 102 for net_af_xdp and 89 for the PCI devarg. Five tests in tests/unit/dev/mt_dev_devargs_test.cpp pin the string the EAL receives, including the unset case and an out-of-range value passed through unvalidated. Four of the 5 failed first, against the bare BDF. Gate 6 is still open: whether the 7-level PF scheduler tree commits on 26.07, which checks depth against hw->num_tx_sched_layers, needs hardware. The field lands either way, because the decision is about the interface. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
MTL_DPDK_HAS_PCAPNG_TS comes from an MTL patch that adds rte_pcapng_copy_ts(). Upstream accepted a different shape for the same feature — a uint64_t timestamp parameter on rte_pcapng_copy(), plus rte_pcapng_tsc_to_ns(). Release v26.07 carries neither shape, so this bump is safe and the next one is not. The comment sits at the guard, not at a call site, because the guard is where the capture is lost: when the define is absent, mt_pcap.h falls back to stubs and packet capture stops with no build error. It names the symbol, the accepted upstream signature, and the patch by Subject: text rather than by number, since the number changes at every bump. The failure analysis stays in upstreaming.md section 7 only, so the 2 copies cannot drift again. Object code is unchanged: build/lib/libmtl.so.p/src_mt_pcap.c.o hashes the same before and after, and ninja -n confirms the object was dirty first, so the rebuild was real. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
tasks.md carries the round's result. Six tasks are DONE, the code half of T-04 closed on Gate 5, T-05 captured 2 of its 3 hardware baseline runs, and the rest is blocked on the host chain T-03, T-35, T-06, T-07 and on a session restart for the MCP servers. Every task numbered T-11 and above was found by a verification pass, not planned. Twenty-seven are open, most of them defects in the carried patch set or in its own record that only a re-measurement could find. The ones that reach outside this move: the unit suite aborts after 46 of 508 tests because a test reaches rte_eal_init(), and no workflow runs that suite at all; 24 files under patches/dpdk/*/windows/ are symlinks a core.symlinks=false checkout turned into text, so the msys2 workflow cannot pass and the version pin is not the reason; the Rust no_std example does not compile and nothing builds it. upstreaming.md keeps the review history only as the evidence for the drop list. Section 3 now records the 5 greps and the 16 dry runs against a real v26.07 tree — 10 apply and 6 fail, which is not the planned 5 and 11 — and section 8 records what the 26.07 patch metadata says now, including the 1 defect that ships on purpose. Two measurements in there change how the host chain must run, and neither was predicted. The installed ice PMD has no rl_burst_size key at all, so a run today returns an unknown-key probe failure and proves nothing about T-04. And /etc/ld.so.conf.d/mtl_local.conf puts a sibling checkout ahead of /usr/local for the same soname, so installing 26.07 does not by itself change what a test loads; every recorded run needs --log_level notice to prove the version from inside the process. report-dpdk-26.07.md is new. It adds no facts. It tells a reader who did not sit through the round what was done, how, and where it stopped, so tasks.md can stay a work list instead of a narrative. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The file carried 6 closed tasks under `## Done` and a `### Where the work stands` narrative, together 317 lines, and both are now recorded in report-dpdk-26.07.md and in git log. A work list that also holds its own history buries the 30 things still to do, which was the state before this change. What went: the `## Done` section, the progress narrative, and the `## Order of work` list, whose 6 numbered steps sequenced T-01, T-02, T-08, T-09 and T-10 and so described a plan that is already spent. What stays untouched: every open task body, the Decisions table, the concurrency and snapshot rules, the irreversible-step constraint, and the Cancelled table, which exists so a missing task does not read as an oversight. The new `## What needs to be done` section is the index the file lacked. It names all 30 tasks once, in 5 groups by what actually blocks them: the 7-step serial chain of the move itself, 6 that need a person rather than a command, 10 that can run today with no host and no decision, 5 patch-metadata repairs, and the 2 long-tail tasks that are the only way to shrink the patch set below 11. Every line names the 1 thing that has to happen, so the reader does not have to open a 60-line task body to learn whether it is actionable. The header now says the file holds open work only, and that a task which closes leaves it. The `## Done` section was itself a task, T-33, and it grew back the moment it existed. Verified: all 30 `## T-` headings appear in the new index, and no index entry names a task that has no body. The one reference to a closed task inside an open body, T-24's `See T-08`, now points at git log instead of a section that is gone. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
versions.env now pins DPDK 26.07 with MTL minor 90, so every flow that reads the pin -- build_dpdk.sh, the patch glob, the drivers script, the docs -- follows one version instead of a version named in prose. This is one snapshot of that move; the pieces landed together on this branch. Patch set: - Restore the 24 destroyed symlinks under patches/dpdk/23.03/windows/, 23.07/windows/ and 23.11/windows/. Each entry held its own link target as file text at mode 100644, so a Windows build applied a one-line patch instead of the real one. They are mode 120000 links again. - The two PHC patches swap places between the 26.03 and 26.07 sets and take the name each set gives them, so a reader diffing the two sets compares the same change under the same number. - Add script/check_dpdk_patches.sh, which applies the pinned version's set to a clean tree, so a stale offset is found before a build finds it. CI and tooling: - Add .github/workflows/unit_tests.yml, called from base_build.yml: the unit tier needs no NIC, so it can gate every push. - Add .github/mcp/test_mtl_mcp_server.py, covering the MCP server the host-setup flow drives. - checkpatch.sh rejects an operand that starts with '-', is empty, or is not a regular file. pre-commit takes the first as a flag and fixes the whole staged set instead, and silently drops a symlink or a directory and exits 0 having checked nothing. - format-coding.sh grows --all, --staged, --files and --preview, and forwards only those modes, so the operand grammar stays in checkpatch.sh with no second copy to drift. - nicctl.sh prints its usage from one block and drops the create_dcf_vf command it no longer supports. Records and docs: tasks.md, upstreaming.md and report-dpdk-26.07.md carry the audit of the carried patches against 26.07 and the defects it found. The driver, Windows build, fuzzing and acceptance guides, the instructions files and the skills follow the same pin. Unit tier: the ptp, st22p, st20_tx and st40 harnesses build against the internals 26.07 exposes. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Every tier above unit takes a different invocation, and the flags that matter -- the two VF BDFs, the pacing way, the gtest filter, the two config paths pytest needs -- were retyped by hand for each run. A mistyped pacing way reads as a pacing regression, which is the failure this is meant to measure. st2110-test/ holds one script per tier: run-kahawai.sh for the integration gtest, run-rxtxapp-loopback.sh for a TX-to-RX loopback over two VFs, and setup-acceptance.sh for the pytest tree. Each takes the two BDFs and reads the rest from the environment, so the same command reproduces a run. README.md gives the host prep once, and ANALYSIS.md maps the scripts onto the tiers and the tasks that ask for them. issue.md states the goal of the DPDK 26.07 move -- carry as few patches as possible, prove it on hardware -- and its critical path, and points at tasks.md for the work list. It is a local working note, not a document for the tree. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The acceptance suite takes a topology file, and the two shapes this host can serve had none: one E830 alone, and an E830 TX side against an E810 RX side over SSH to localhost. Both were assembled by hand before each run, which is how a run ends up measuring a different link than the one it names. topology_single_e830.yaml is the single-host shape; topology_dual_vf.yaml is the two-sided one, with the card, the BDF and the NUMA node of each leg recorded in a comment so a wrong NIC is visible in the file rather than in the results. Both carry this host's paths and key, so they are a starting point to copy, not a fleet config. .gitignore drops scripts/dpdk, which a local DPDK checkout lands in and which the suites that assert on `git status` would otherwise see. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Hardware rate-limit pacing needs a patched ICE, and the pinned 2.6.6 set was the only one in the tree. It also needs a patched iavf, which build_drivers.sh could not build at all, so that half was a manual step no script recorded -- and an unpatched iavf is what a SEGFAULT in iavf_tm_node_add reports. versions.env pins ICE 2.6.7 with its download-mirror id, and adds IAVF_VER and IAVF_DMID beside them, so both driver versions come from the same place as every other pin. patches/ice_drv/2.6.7/ carries the five patches the public 2.6.7 release does not: the runtime rate-limit queue the VF needs, the 2 KB TX scheduler burst size, VIRTCHNL_VF_LARGE_NUM_QPAIRS against a larger LUT, the legacy MAP_QUEUE_VECTOR size calculation, and the Kahawai version string that modinfo reports. build_drivers.sh gains build_iavf and the flags around it: --driver iavf, --disable-iavf, --iavf-version, --iavf-download-id, and a version check that skips the rebuild when modinfo already reports the wanted Kahawai version. --build-only leaves the compiled module in the source tree for a packager to stage. The download falls back to the ethernet-linux-iavf tag when the Intel mirror does not answer. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The 26.07 set carried a local rewrite of the iavf runtime-queue change under the short name 0002-iavf-disable-runtime-queue.patch. Upstream has moved on: v6 of the same change is on dev@dpdk.org, and MTL should carry that text so the next rebase is a re-apply and not a re-derivation. Replace it with 0002-net-iavf-disable-runtime-queue-setup-during- queue-rate-limiting.patch, the posted v6 mail as sent, name and Message-ID included, so the thread the patch came from is reachable from the file. Drop 0003-pcapng-add-user-timestamp-support.patch and hdr_split/0001-net-intel-ice-support-hdr-split-mbuf-callback.patch from the 26.07 set. Neither is part of what this branch validates on 26.07. upstreaming.md and report-dpdk-26.07.md still describe both, so that record needs a follow-up pass. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
ice and iavf ship as one artifact. build-ice.sh compiles both via build_drivers.sh --build-only and stages ice.ko + iavf.ko under one cache entry with one metadata.env; validate-ice.sh and activate-ice.sh check and load both. The validate-host action already restores and activates that package, so a test host gets both Kahawai drivers the same way -- no separate build step at test time. - build_drivers.sh: build_iavf now honours --build-only, leaving iavf-<ver>/src/iavf.ko in place for the packager, and builds with the CI-enforced compiler -- mirroring build_ice. - build-ice.sh: stage iavf.ko and record its version/dmid/vermagic/sha256/ signer/sig_id; metadata schema 2 -> 3. - validate-ice.sh: require every iavf field and verify the module sha256, vermagic compatibility, signer, and Secure Boot signing. - activate-ice.sh: install iavf.ko to updates/ and reload it when loaded; an unloaded VF driver is left for the kernel to auto-load from that path. - hash_sources_ice.env: hash patches/iavf_drv/ so an iavf change rebuilds the package. - Drop the standalone build-iavf workflow step (it referenced a job that no longer exists); the package flow replaces it. The setup_environment.sh iavf flow stays for manual, non-CI hosts. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Commit-message format was the one MTL convention with no mechanical check. The type set, the 72-char subject and the Signed-off-by trailer were review items only, so a malformed subject could reach main unnoticed. Add gitlint to .pre-commit-config.yaml, which stays the single source of truth for tool and pinned version, and keep its rule content in .github/linters/.gitlint like every other linter. A linter.yml job runs the same hook over a pull request's commit range. Section 7 of doc/coding_standard.md documents the rules and the three body checks that are disabled on purpose. Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
DawidWesierski4
requested review from
Sakoram,
awilczyns,
moleksy and
soopel
as code owners
August 26, 2026 18:39
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
DawidWesierski4
force-pushed
the
dpdk-26.07-on-cicd_desgin
branch
from
August 26, 2026 19:13
ad6c075 to
da9c10e
Compare
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
The ICE series was generated against an internal tree whose sources are split into src/CORE/ and src/SHARED/. build_drivers.sh builds the public ethernet-linux-ice release, which keeps every source file flat in src/, so patches 1-3 found no file to patch and CI failed with "4 out of 4 hunks ignored". Regenerate the three patches against ice-2.6.7 as published, and add the IAVF counterpart of the virtchnl MAP_QUEUE_VECTOR size fix. The PF-side fix alone leaves the two sides of the ABI disagreeing, so the VF copy of virtchnl.h has to move with it. Pass --batch to patch so a series that does not fit the release fails the build instead of stopping on "File to patch:" and waiting for a terminal no CI runner has, and report which patch failed. Ignore script/iavf-* the way script/ice-* already is, so --build-only leaves no untracked tree behind. Verified on 6.8.0-138-generic: script/build_drivers.sh --build-only applies all six patches clean and builds ice.ko (Kahawai_2.6.7) and iavf.ko (4.13.35). Change-type: BugFix Signed-off-by: Wesierski, Dawid <dawid.wesierski@intel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.