ci: migrate libyang1 deb install to libyang3#113
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
bhouse-nexthop
force-pushed
the
bhouse.libyang3-debs
branch
from
3e2c245 to
f778a44
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
sonic-buildimage no longer builds the libyang1 debs (libyang_1.0.73, libyang-cpp, python3-yang); it now builds only libyang3. - .azure-pipelines/build.yml: download the libyang3 debs from the common_libs artifacts using versionless globs (libyang3_*.deb, libyang-dev_*.deb) instead of the libyang1 patterns. - .github/workflows/codeql-analysis.yml: install libyang-dev from the distro apt repo in the prepare step (matching the other SONiC repos' CodeQL workflows, e.g. sonic-sairedis / sonic-linkmgrd) and drop the hardcoded sonic-build libyang1 deb downloads. - lgtm.yml: keep the apt-provided libyang-dev; drop the bare libyang entry. Part of sonic-net/sonic-buildimage#22385. Signed-off-by: Brad House <bhouse@nexthop.ai>
bhouse-nexthop
force-pushed
the
bhouse.libyang3-debs
branch
from
f778a44 to
14a7ff1
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Commenter does not have sufficient privileges for PR 113 in repo sonic-net/sonic-dhcp-relay |
rookie-who
left a comment
rookie-who
left a comment
There was a problem hiding this comment.
The Azure Pipelines changes look good — clean libyang1 → libyang3 swap.
However, the CodeQL workflow change needs a second look: the old code installed SONiC-built libyang debs (specific 1.0.73 versions), but the new code switches to system libyang-dev via apt-get install. The system package from Debian apt may provide libyang2 headers, not libyang3. If the build links against libyang3 APIs, this could cause a version mismatch or build failure in CodeQL analysis.
Consider either:
- Installing the SONiC-built
libyang3andlibyang-devdebs in the CodeQL workflow (matching the Azure Pipelines approach), or - Verifying that the system
libyang-devpackage provides libyang3-compatible headers.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run |
|
Retrying failed(or canceled) jobs... |
|
No failed(or canceled) stages or jobs found in the most recent build 1129422. |
|
/azpw run |
|
Retrying failed(or canceled) jobs... |
|
No failed(or canceled) stages or jobs found in the most recent build 1129422. |
4 participants
Why I did it
sonic-buildimageno longer builds the legacy libyang1 debs (libyang_1.0.73,libyang-cpp,python3-yang); it now builds only libyang3 (libyang3,python3-libyang). The CI here still referenced the libyang1 debs and would break once libyang1 is gone.Part of the libyang3 migration tracked in sonic-net/sonic-buildimage#22385.
How I did it
.azure-pipelines/build.yml— download the libyang3 debs from thecommon_libsartifact using versionless globs (libyang3_*.deb,libyang-dev_*.deb) instead of the libyang1 patterns..github/workflows/codeql-analysis.yml— installlibyang-devfrom the distro apt repo in thepreparestep (the same approach the other SONiC repos' CodeQL workflows already use — e.g. sonic-sairedis, sonic-linkmgrd, sonic-wpa-supplicant) and drop the hardcodedsonic-buildlibyang1 deb downloads. This avoids pinning a libyang version in the workflow.lgtm.yml— keep the apt-providedlibyang-dev; drop the barelibyangentry.How to verify it
The azure build downloads/install the libyang3 debs from current
sonic-buildimagemaster; the CodeQL build resolves libyang headers from the distrolibyang-dev, consistent with the other repos. No libyang version is hardcoded anywhere.Description for the changelog
ci: migrate libyang1 references to libyang3 (azure build artifacts + CodeQL).