Skip to content

ci: register hi3516cv200_neo + hi3516av100_neo in build.yml matrix#2124

Merged
widgetii merged 1 commit into
masterfrom
fix/2122-add-cv200-av100-neo-to-build-matrix
May 22, 2026
Merged

ci: register hi3516cv200_neo + hi3516av100_neo in build.yml matrix#2124
widgetii merged 1 commit into
masterfrom
fix/2122-add-cv200-av100-neo-to-build-matrix

Conversation

@widgetii
Copy link
Copy Markdown
Member

Summary

Fixes a miss in #2122. The defconfigs, board files, and post-image scripts landed, but the two new boards were not added to .github/workflows/build.yml's platform: matrix list. That list is hand-maintained — entries control which firmware variants the nightly cron builds and which tarballs end up in the latest release. Without the entries, the nightly never produced openipc.hi3516cv200-nor-neo.tgz or openipc.hi3516av100-nor-neo.tgz, even though the build does work locally (verified end-to-end in #2122).

Adds two entries:

  • hi3516cv200_neo under # Hisilicon [HI3516CV200]
  • hi3516av100_neo under # Hisilicon [HI3516AV100]

After this lands, the next scheduled nightly will publish the neo tarballs alongside the lite ones, unblocking the follow-up openhisilicon CI-row addition (this issue #2123 → openhisilicon matrix rows that depend on these tarballs existing).

Test plan

  • YAML parses cleanly
  • PR CI exercises the two new matrix rows — must reach success for cv200_neo and av100_neo before merge
  • Next nightly publishes both tarballs to latest

🤖 Generated with Claude Code

…loses #2123)

#2122 added the defconfigs + board files + post-image scripts but
missed adding the two new boards to .github/workflows/build.yml's
`platform:` matrix list. That list is hand-maintained — entries
control which firmware variants the nightly cron builds and which
tarballs end up in the `latest` release. Without the entries, the
nightly never produced openipc.hi3516cv200-nor-neo.tgz or
openipc.hi3516av100-nor-neo.tgz, even though the build does work
locally (verified end-to-end in #2122).

Two entries added in the existing per-vendor sections:
  - hi3516cv200_neo  (under Hisilicon [HI3516CV200])
  - hi3516av100_neo  (under Hisilicon [HI3516AV100])

After this lands, the next scheduled nightly publishes the neo
tarballs alongside the lite ones, unblocking the followup
openhisilicon CI-row addition (#2123 → openhisilicon
matrix rows that depend on these tarballs existing).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@widgetii widgetii merged commit ce2758a into master May 22, 2026
95 checks passed
widgetii pushed a commit to OpenIPC/openhisilicon that referenced this pull request May 23, 2026
…m firmware)

Now that the firmware nightly publishes openipc.hi3516cv200-nor-neo.tgz
and openipc.hi3516av100-nor-neo.tgz (after OpenIPC/firmware#2124 added
both boards to the firmware build.yml matrix), wire two new rows into
the qemu-boot job.

Each row downloads the appropriate -nor-neo.tgz from the latest
firmware release and runs the same boot smoke as the lite rows.

Local pre-merge validation against the published nightly tarballs:

  hi3516cv200_neo:
    [PASS] login (openipc-hi3516cv200 login:)
    [PASS] IP (10.0.2.15 via SLIRP DHCP)
    [PASS] ping 10.0.2.2

  hi3516av100_neo:
    [PASS] login (openipc-hi3516av100 login:)
    [PASS] IP (10.0.2.15 via SLIRP DHCP)
    [PASS] ping 10.0.2.2

Both also clean on Oops/panic/BUG/Call Trace patterns.

Row mechanics — new optional `variant:` field:

  - Defaults to lite. Rows that don't set it stay byte-equivalent
    (download URL becomes openipc.X-nor-lite.tgz, row name unchanged).
  - When `variant: neo`:
      * row name becomes "QEMU boot (<machine>_neo)"
      * download URL becomes openipc.<machine>-nor-neo.tgz
      * upload-artifact name becomes "qemu-boot-<machine>_neo"

Both new rows are real gates (no allow-failure: true). load_hisilicon
on neo doesn't load HiSi blobs (kernel-version path mismatch — separate
firmware follow-up to teach it the /lib/modules/7.0 path), so neither
row sets min_modules; the assertion is "login reached + no error
patterns". That's what the local DoD test exercises and what the CI
will exercise.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
widgetii added a commit to OpenIPC/openhisilicon that referenced this pull request May 23, 2026
…m firmware) (#181)

Now that the firmware nightly publishes openipc.hi3516cv200-nor-neo.tgz
and openipc.hi3516av100-nor-neo.tgz (after OpenIPC/firmware#2124 added
both boards to the firmware build.yml matrix), wire two new rows into
the qemu-boot job.

Each row downloads the appropriate -nor-neo.tgz from the latest
firmware release and runs the same boot smoke as the lite rows.

Local pre-merge validation against the published nightly tarballs:

  hi3516cv200_neo:
    [PASS] login (openipc-hi3516cv200 login:)
    [PASS] IP (10.0.2.15 via SLIRP DHCP)
    [PASS] ping 10.0.2.2

  hi3516av100_neo:
    [PASS] login (openipc-hi3516av100 login:)
    [PASS] IP (10.0.2.15 via SLIRP DHCP)
    [PASS] ping 10.0.2.2

Both also clean on Oops/panic/BUG/Call Trace patterns.

Row mechanics — new optional `variant:` field:

  - Defaults to lite. Rows that don't set it stay byte-equivalent
    (download URL becomes openipc.X-nor-lite.tgz, row name unchanged).
  - When `variant: neo`:
      * row name becomes "QEMU boot (<machine>_neo)"
      * download URL becomes openipc.<machine>-nor-neo.tgz
      * upload-artifact name becomes "qemu-boot-<machine>_neo"

Both new rows are real gates (no allow-failure: true). load_hisilicon
on neo doesn't load HiSi blobs (kernel-version path mismatch — separate
firmware follow-up to teach it the /lib/modules/7.0 path), so neither
row sets min_modules; the assertion is "login reached + no error
patterns". That's what the local DoD test exercises and what the CI
will exercise.

Co-authored-by: Vasiliy Yakovlev <vixand@openipc.org>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant