Repository navigation
ci: pin EoSim to a tag that exists - #106
Merged
srpatcha merged 9 commits intoSep 1, 2026
Merged
Conversation
…ckend
Which backend source CMake compiles and which registrar eos_hal_init() calls
are the same decision made in two places, with two different conditions.
CMakeLists.txt:
if(EOS_PLATFORM STREQUAL "linux" OR NOT CMAKE_CROSSCOMPILING)
target_sources(eos_hal PRIVATE hal/src/hal_linux.c)
else()
target_sources(eos_hal PRIVATE hal/src/hal_rtos.c)
hal_common.c:
#ifdef __linux__
eos_hal_linux_register();
#else
eos_hal_rtos_register();
They agree on Linux and on a cross build, and disagree on every other host. A
macOS host build compiles hal_linux.c, then references a symbol from the file
it did not compile:
Undefined symbols for architecture arm64:
"_eos_hal_rtos_register", referenced from: _eos_hal_init
CMake now sets EOS_HAL_BACKEND_HOST or EOS_HAL_BACKEND_RTOS next to the
target_sources() call that makes the choice, and hal_common.c keys off that.
__linux__ stays as a fallback for anyone compiling these files without CMake.
Two things had to move with it:
- hal.h declared the registrars under the same #ifdef, so hal_common.c could
not even name the one CMake had compiled. Both are declared unconditionally
now; exactly one is still defined per build, and an unreferenced declaration
costs nothing. The header's own comment already argued for this -- "an
undeclared registrar is one nobody can find".
- hal_linux.c wraps its whole body in #ifdef __linux__, so on macOS it compiled
to an empty translation unit and the build had no backend at all. It is the
host backend rather than the Linux one: the only platform calls in it are
clock_gettime() and nanosleep(), both POSIX. Guarded on the CMake define,
with __linux__ as the fallback. hal_rtos.c takes the mirror condition.
Linux behaviour is unchanged: EOS_HAL_BACKEND_HOST and __linux__ are both
defined there, and the same registrar is selected as before. Cross builds get
EOS_HAL_BACKEND_RTOS and are likewise unchanged. eos master CI is green on
Linux and stays that way.
Verified on macOS: the eos_hal link error is gone and ctest goes from 0/28 to
19/28.
This does NOT make macOS a supported host on its own. The remaining 9 failures
are services/compat/src/os_adapter_posix.c calling pthread_mutex_timedlock()
and sem_timedwait(), neither of which macOS provides. That is a separate piece
of work in a different subsystem and I have not attempted it here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
With -DEBLDR_BOARD=qemu_arm64 actually taking effect (it was -DBOARD= before
and silently ignored), eBoot's configure now runs the board path and refuses:
EBLDR_VERIFY_STAGE1 is ON but board qemu_arm64 has no stage-1 linker
script, so there is no stage-1 image to hash. Configure with
-DEBLDR_VERIFY_STAGE1=OFF to build stage-0 without the integrity check.
That refusal is correct -- the board ships only board_qemu_arm64.c/.h, no
linker scripts, so there is no stage-1 image for stage-0 to verify -- and the
message names the flag. Passed here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The QEMU step ran for ~20ms, left an empty serial log, and reported nothing -- because its stderr went to /dev/null and its exit code into `|| true`. The one message that says why the guest did not boot was the message being thrown away. Keep the run non-fatal only for exit 124 (timeout(1) killing a still-running guest, which is how a bare-metal image "finishes"); any other nonzero exit now fails the step loudly with QEMU's own stderr printed. Also list the artifact files before booting, so a missing or truncated eos_qemu.bin is visible. The TC validation gate below is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
With stderr finally visible, the reason the guest never booted is one line:
qemu-system-aarch64: failed to find romfile "efi-virtio.rom"
The workflow installs qemu-system-arm with --no-install-recommends, which
skips ipxe-qemu -- the package that ships efi-virtio.rom. The virt machine
creates a default virtio-net device, that device wants its boot ROM, and QEMU
exits during machine init. This has been the failure since the job first ran;
it was just invisible behind 2>/dev/null.
The simulation uses no networking, so -nic none removes the device rather
than installing a ROM for a NIC nothing talks to.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Build & Test (Linux x86_64) job hangs in "Run C unit tests" and holds the workflow open until GitHub's 6-hour limit. Which test hangs is currently unknowable from the outside: ctest runs with no per-test timeout, so the job never reaches the summary that would name it. --timeout 120 turns the invisible hang into a named failure. 120s is generous -- the slowest test in this suite takes 1.4s. Second, related: the concurrency group I added cancels in-progress runs on every push. Right for PR branches; wrong for master, where each merge cancelled the previous merge's run -- which is why this job has not been allowed to COMPLETE on master since 08-30 and the hang went unnoticed. cancel-in-progress is now conditional on the ref not being master. Verified locally (macOS): ctest 25/28 pass with the timeout flag; the 3 remaining are Not Run because test_os_adapter/test_os_services/test_ota do not build here (the known pthread_mutex_timedlock/sem_timedwait gap). Those three are Linux-only -- exactly the ones this timeout will name if one of them is the hang. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The test named by the new ctest timeout is test_net, and the hang is not a
networking bug. CI builds Release; Release defines NDEBUG; NDEBUG deletes
assert() together with the expression inside it. Half of test_net's checks
wrap the call under test:
assert(eos_net_connect(c, &addr) == 0);
assert(eos_net_send(c, "ping", 4) == 4);
With those gone, no client ever connects, the echo thread blocks in accept()
forever, and pthread_join() hangs the suite -- for exactly as long as nothing
bounds the test, which is what the previous commit fixed.
Reproduced locally before fixing: a Release build of the unmodified test hangs
on macOS too (this was never Linux-specific; my earlier local runs simply were
not Release). Replaced every assert() with a CHECK() macro that always
evaluates and exits nonzero on failure.
After: Release test_net passes 19/19 in under a second; full local Release
ctest 27/28 (the 1 is test_os_adapter, Not Run on macOS as known).
Same latent class elsewhere: other C tests also use assert() and silently
check nothing in Release builds -- they pass today because their expressions
have no needed side effects that block, but they are weaker than they look.
Worth a sweep in its own PR rather than burying it here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The ARM Cortex-M4 job caught a regression in my backend-selection change:
hal/src/hal_linux.c:30:10: fatal error: sys/ioctl.h: No such file or directory
That cross build also compiles hal_linux.c -- EOS_PLATFORM defaults to
"linux", so CMake's host branch is taken even for arm-none-eabi -- and it only
ever built because `#ifdef __linux__` reduced the file to an empty translation
unit there. Widening the guard to EOS_HAL_BACKEND_HOST un-emptied it on a
toolchain with no POSIX headers.
The guard now asks the right question -- "is this a hosted POSIX build?" --
once, in hal.h:
#if defined(__linux__) || \
(defined(EOS_HAL_BACKEND_HOST) && (defined(__unix__) || defined(__APPLE__)))
#define EOS_HAL_HOSTED 1
and hal_linux.c, hal_rtos.c and hal_common.c all key off EOS_HAL_HOSTED
instead of each doing their own arithmetic. arm-none-eabi defines none of
those macros, so the empty-TU behavior the ARM job depends on is restored;
aarch64-linux-gnu defines __linux__, so the QEMU simulation lane is unchanged;
macOS defines __APPLE__, so the original fix stands.
Verified locally by preprocessing hal_linux.c both ways (clang -U__APPLE__
-U__unix__ -U__linux__ simulating bare metal: body absent; hosted: present)
and a full Release build + ctest: 26/28, the 2 remaining being the documented
macOS Not-Runs (pthread_mutex_timedlock/sem_timedwait).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
EoSim Sanity has never had a green run in this repository. EOSIM_VERSION is
"0.1.0" and embeddedos-org/EoSim has no such tag -- its tags run v1.0.0 through
v3.0.1 -- so every job dies at the clone:
fatal: Remote branch v0.1.0 not found in upstream origin
and then, predictably, at the install:
ERROR: file:///tmp/EoSim does not appear to be a Python project:
neither 'setup.py' nor 'pyproject.toml' found
The second message is a red herring: the directory is empty because the clone
failed, not because EoSim is not a Python project. It is one -- v1.5.0 carries
a pyproject.toml declaring name = "eosim" with a console entry point.
Pinned to v1.5.0, the release marked Latest. Verified by doing exactly what the
workflow does:
git clone --depth 1 --branch v1.5.0 .../EoSim.git /tmp/EoSim
pip install /tmp/EoSim -> rc=0
eosim --version -> eosim, version 2.0.0
eosim list -> rc=0
eosim doctor -> rc=0
Those four are every EoSim command this workflow invokes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kartikey1306
force-pushed
the
fix/eosim-sanity-real-tag
branch
from
September 1, 2026 06:50
8c0025d to
13b631d
Compare
Contributor
Author
|
Stacked on #102 — the red check was |
srpatcha
approved these changes
Sep 1, 2026
srpatcha
pushed a commit
that referenced
this pull request
Sep 8, 2026
…129) * fix(build): restore the low-order Ed25519 suite that #93 removed `CI — eos` and `Python Unit Tests` are red on master (769191a), and both fail for one reason: these suites exist in tests/ but no add_executable() in tests/CMakeLists.txt builds them, so they never run: ['test_crypto_ed25519_loworder.c'] 3aa8644 (#93, "remove duplicate test targets from tests/CMakeLists.txt") removed all four lines that build and register test_crypto_ed25519_loworder. It was not a duplicate — there was exactly one registration before that commit, and it took it. What stopped running is the suite that guards #101: Ed25519 rejecting low-order public keys. A low-order key makes every term of the verification equation collapse to the identity regardless of the message, so a signature of all zeros verifies against any content at all. The fix is still in services/crypto/src/ed25519_verify.c and still correct; nothing has been checking it since #93 merged, and nothing would have noticed if a later change had removed it too. Restored verbatim from 3aa8644^, in its original position before test_crypto_sha512. No other file changes. The guard that caught this is test_cmake_test_registration.py, added recently. It did exactly its job — this is the first thing it found. Verified: test_cmake_test_registration.py -> 5 passed (1 failed on master) pytest tests/ -> 15 passed (14 passed 1 failed on master) test_crypto_ed25519_loworder -> 5/5 tests passed ctest -> 39/39 passed (master builds 38) * ci: finish the EoSim fix — a tag that exists, and no wheel anywhere `Simulation Test` and `EoSim Sanity` are both red on master. #106 fixed this class in eosim-sanity.yml but did not reach every site. simulation-test.yml still pins EOSIM_VERSION: "0.1.0". EoSim has no v0.1.0 tag — its releases run v1.0.0 to v3.0.1 — so every run failed at the clone: fatal: Remote branch v0.1.0 not found in upstream origin Bumped to 1.5.0, the release marked Latest and the one eosim-sanity.yml already pins. eosim-sanity.yml still installs a wheel on its Windows and macOS legs: ERROR: HTTP error 404 while getting .../releases/download/v1.5.0/eosim-1.5.0-py3-none-any.whl No EoSim release ships a wheel, so that URL 404s at any version — the version bump alone could never fix these two. The other three jobs in the same workflow already install from a clone; these two were missed. Converted to the same clone + `pip install -e`. Verified, against the real remote rather than from the error message: wheel URL -> HTTP 404 git ls-remote --tags | v0.1.0 -> 0 matches git ls-remote --tags | v1.5.0 -> 1 match clone v1.5.0 + pip install -e -> rc 0 eosim --version -> eosim, version 2.0.0 eosim doctor -> rc 0 (The v1.5.0 tag reporting version 2.0.0 is EoSim's own inconsistency, not a wrong pin — v1.5.0 is what its releases page marks Latest.) Both files still parse as YAML. Stacked on the #127 registration fix so this branch's CI is not red for an unrelated reason. * ci(eosim): pin the commit, assert the version pip resolved, and let the workflow test itself Answers the review on #129. The two diagnoses in the previous commit hold -- there is no v0.1.0 tag and no EoSim release ships a Python artifact -- and this addresses what the replacement pin did not. Finding 1 (High) -- `EOSIM_VERSION: "1.5.0"` is a label, not a version. Re-verified against the remote rather than taken from the review: tag commit committed commit subject pyproject __init__ v1.5.0 7dec3460 2026-05-27 "production-ready v1.4.0" 3.0.1 3.0.1 v3.0.1 b297ec26 2026-05-16 "v3.0.1 — unified ..." 3.0.1 2.0.0 v1.5.0 is the release GitHub marks Latest and the newest tag by commit date, tags a commit whose own message claims v1.4.0, and installs a dist declaring 3.0.1. A reader of `EOSIM_VERSION: "1.5.0"` would believe eos is simulated against EoSim 1.5.0. It is not, and nothing in the file would reveal that. Both workflows now pin `EOSIM_COMMIT` to the full SHA that tag resolves to today, with the table above in the env block and the date it was checked. Not v3.0.1 instead: its `__init__.py` says 2.0.0, so it is only marginally less confusing. A SHA cannot be moved under us; the comment says to go back to a tag once EoSim's tags mean something. Finding 3 (Medium) -- `eosim --version` cannot detect a wrong install. EoSim hardcodes it (`eosim/cli/main.py:49`, `@click.version_option(version="2.0.0")`), confirmed by reading that file at v1.5.0, so it prints 2.0.0 from every tag -- which is exactly why the previous commit could record the version oddity as a curiosity rather than as a failed pin. All three sites now also assert `importlib.metadata.version("eosim")` against `EOSIM_EXPECTED_DIST`, which is the only version the commit pin controls. Finding 4 (Medium) -- this PR could not be validated by CI and was not: both workflows were schedule- and dispatch-only, so neither appeared in this head's checks and all 25 green ones were other workflows. Added `pull_request: paths:` on both files listing both files, so a change to either now runs both. `workflow_dispatch` on the fork is not available to me -- GitHub resolves the workflow on the fork's default branch and returns 404 -- so this trigger is the evidence that is actually obtainable, and it applies to every future change to these files rather than to this one only. Finding 2 (High) -- after this, nothing in the org exercises a published EoSim artifact, and none exists. Verified independently: 13 releases whose assets are promo .mp4 files, a manifest.json and EoSim-guide.pdf; no wheel or sdist at any tag; `https://pypi.org/pypi/eosim/json` returns 404. Converting to a clone is right -- a permanent 404 is not a useful red -- but it would also make the gap green and invisible, which is the "verification whose result is discarded" shape. So `published-artifact-watch` runs on every execution, checks the releases and PyPI, and says out loud that the packaging debt is open. It cannot fail the workflow, deliberately: it is a tracking signal, not a gate on someone else's repo. It emits a `::notice::` the day an artifact appears, which is when it should be deleted and the installs pointed at it. The debt is also stated in the PR body rather than left implied, and raised against EoSim. Finding 5 (Low) -- `/tmp/EoSim` was hardcoded in the two jobs that run on windows-latest and macos-latest, where the Windows job sets no `shell:` and gets pwsh. Now `${{ runner.temp }}/EoSim` everywhere. Finding 6 (Low) -- dropped `-e`. Nothing needs an editable install, it is further from what a developer does in a workflow meant to prove the install works, and it made the dist-metadata assertion depend on the clone staying put. Changed at all five sites, not two, so they are consistent. Also, while in this file: `sanity-gate` had the fail-open shape -- `needs:` five jobs, tested `install-validate` alone, then printed "All EoSim sanity checks passed". Replaced with the `toJSON(needs)` body, which cannot fall out of step with `needs:`, and the new job is included in it. Verified: ctest 39/39 PASS pytest tests/ 15 passed both workflows parse, and structurally: pull_request paths list this file both EOSIM_VERSION gone from every code line both EOSIM_COMMIT is a full 40-char sha both no /tmp/EoSim literal, no `pip install -e` both every `git clone --filter` has a matching `checkout --detach` three importlib.metadata assertions sanity-gate needs == every other job in the file the SHA resolves: refs/tags/v1.5.0 -> tag object 978f215f -> commit 7dec3460cba76083b6645eb4a867e39aa2af97df NOT RUN: neither workflow. `workflow_dispatch` on the fork returns 404 because GitHub resolves it on the fork's default branch. The `pull_request: paths:` trigger should make both run on this PR for the first time -- that will be the first execution either has ever had, and I will report what it shows rather than predicting it. Finding 7 (Low): still stacked on #127; the tests/CMakeLists.txt hunk goes when that lands. Refs #129 * ci(eosim): copy platforms/ in every job that runs a simulation The first real execution of these workflows -- which the pull_request trigger added in the previous commit made possible -- failed, and showed the next blocker behind the missing v0.1.0 tag: FileNotFoundError: [Errno 2] No such file or directory: '/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/site-packages/platforms' on all three Guest OS Install legs and all seven Nested Simulation platforms. platforms/ is data, not package data: eosim/cli/main.py sets PLATFORMS_DIR to <site-packages>/platforms while the wheel ships only eosim/platforms/__init__.py. None of the five jobs that run eosim copied it, so none of them could ever have worked. A tag that exists was necessary and not sufficient, exactly as the review said. Worth recording: this is also what the dropped `pip install -e` was accidentally papering over in the jobs that had a copy elsewhere. With an editable install eosim.__file__ points into the clone, so PLATFORMS_DIR landed beside the checked-out platforms/ by luck. A plain install is the right thing and it made the real dependency visible. install-validate went green in that run and the tracking job reported the packaging debt as intended; the failures were confined to the jobs that actually boot a platform. Verified: both workflows parse; all five eosim-running jobs now copy platforms/ the run that produced the error: 33783625398 (EoSim Sanity), first execution this workflow has ever had Refs #129 * ci(eosim): run the bash steps in bash, including on the Windows legs Second real execution, after the platforms/ fix: ubuntu and macOS now pass Install & Validate; all three windows-latest legs fail. Install & Validate (windows-latest, Python 3.12) # FileNotFoundError: .../site-packages/platforms ##[error]Process completed with exit code 1 The give-away is the leading `#` in that line: pwsh echoed my comment as a command. install-validate is a matrix over ubuntu/windows/macos and set no `shell:`, so on the Windows legs it got the runner default, where `VAR=$(...)`, `cp -r` and a leading `#` are all wrong. windows-sanity had the same gap. `shell: bash` on the six run steps in the two Windows-capable jobs. This is the same defect the review raised as finding 5 for the hardcoded /tmp path -- ${{ runner.temp }} fixed where the clone goes, and this fixes what interprets the script. Worth stating plainly: none of this was visible before the pull_request trigger. Two runs have now found two blockers behind the missing v0.1.0 tag -- platforms/ never copied in any job, and bash steps running under pwsh -- in a workflow that had never executed once. The trigger is doing more work than the pin. Verified: parses; no run step in a windows-capable job is left without a shell run 33784349071: ubuntu + macOS Install & Validate green, windows red with the error above Refs #129 * ci(sim): run the bash steps in bash on the Windows leg too Third run. EoSim Sanity is green -- 23/23 jobs, the first green run that workflow has ever had. Simulation Test has one failure left, `Cross-Platform (windows-latest)`, and it is the same defect I fixed in eosim-sanity.yml one commit ago and did not apply here: Cross-Platform (windows-latest) Install EoSim from source # fails with FileNotFoundError. ##[error]Process completed with exit code 1 pwsh echoing a `#` comment as a command. The cross-platform matrix includes windows-latest and its two run steps set no `shell:`. Refs #129 * ci(eosim): one install recipe, gates that refuse empty input, and a watch that stops posing as a check Answers the overnight review on #129. Finding 3 (Low, and the structural one) -- the five-line install recipe was copy-pasted at seven sites across two workflows, and the PR's own history shows the cost: -e dropped "at all five sites, not two", runner.temp at all of them, shell: bash at several, each a separate round because each site was a separate edit. Now .github/actions/install-eosim owns it -- clone at the pinned commit, install, stage platforms/, assert the dist version -- and all seven sites are a four-line `uses:`. The platforms/ workaround and the version assertion get one place to be deleted from when EoSim fixes its packaging. The triplicated inline importlib.metadata assert is gone with it. Finding 5 (Low), folded into the composite -- SITE_PACKAGES comes from sysconfig.get_paths()["purelib"], which needs no import and cannot be shadowed, matching eBoot's copy of the workaround instead of solving the same problem a second way. Finding 1 (Medium) -- the inline gate accepted nothing as everything: an empty RESULTS printed "All EoSim sanity jobs succeeded." and exited 0, and null produced a raw jq error, where eos#121's extracted ci-gate-check.sh refuses both. Both gates now refuse empty/null input with a diagnosis before jq runs, under set -euo pipefail, and carry a note to become a call to #121's script once it is on master so the two cannot drift. Reproduced the review's side-by-side on the hardened body: "" rc=1 gate received no results to check (was rc=0 PASS) null rc=1 gate received no results to check (was raw jq error) {} rc=0 PASS -- shared with #121's script; reported there, and [] rc=0 PASS unreachable here: needs has five entries skipped rc=1 FAIL: a: skipped success rc=0 PASS Also applied to simulation-test.yml's Simulation Gate, which still had the original fail-open shape -- needs: [simulate, cross-platform], a test of `simulate` alone, then "All simulation tests passed". Same toJSON(needs) body, same guards. Finding 4 (Low) -- published-artifact-watch could not fail and sat in sanity-gate's needs under a name that made a green tick assert a deficiency. Now "EoSim artifact publication (informational)", schedule/dispatch only, out of the gate: pull requests no longer carry a permanently-green status about another repository's release process, and the debt still gets said out loud every night. Finding 6 (Low) -- simulation-test's EOSIM_COMMIT comment argued tag selection for what is now a SHA; it now states the actual reason (EoSim's tag names do not identify their contents) and gains the EOSIM_EXPECTED_DIST the composite asserts. Finding 2 (Medium) is a two-line change in eos#121's registry, not here -- both workflows need NOT_REQUIRED entries with a paths-filter reason once both PRs land, or #121's classification test fails. Posted on both threads with the exact entries; not folded in, because that registry lives on #121's branch and this PR must not carry another PR's hunks. Verified locally before push: all three YAML files parse composite referenced at 7 sites; zero inline clone/install/copy remnants eosim-sanity gate needs == every job except itself and the informational watch; sim gate iterates toJSON(needs), no single-dependency branch the five-input table above, executed the workflows themselves: this push's pull_request run is the test, and I will report what it shows rather than predict it. Refs #129 * ci: pin the eBoot and ebuild checkouts instead of floating on master Every open eos pull request is currently red on `EoS Full-Stack Simulation`, and none of them caused it. The kernel job checks out embeddedos-org/eBoot at `ref: master`, and eBoot master does not compile: include/eos_image.h:135 and :142 static-assert offsetof(eos_image_header_t, reserved) for a member that became tlv_len + tlv_hash, and core/ed25519_verify.c redefines point_is_identity -- two pairs of PRs that each merged clean and broke the build together. eBoot #94 repairs it and waits on review; until it lands, no change to any eos PR can make this job pass, and after it lands the next broken eBoot master does the same thing again. A floating `ref: master` makes every eos PR's CI depend on the moment-to- moment state of another repository's default branch. Pinning the two compiled-against checkouts makes the job a function of this repository plus two recorded SHAs -- red means the PR broke something, green means it did not, and a cross-repo bump is a reviewable one-line diff with CI on it. EBOOT_COMMIT a172a6d6e1e6 the newest eBoot master ancestor that compiles; found by walking master back and building each candidate. Its child 8a015b2 already carries the ed25519 redefinition. EBUILD_COMMIT e5d8052f3e2c ebuild's current master, frozen as-is. Both of its checkouts feed steps that are commented out (eFab does not exist), so this pin only removes the float. The middleware matrix (10 repos) still floats; it runs those repos' own tests rather than compiling eos against them, and 10 more pins deserve their own decision. When eBoot #94 merges, bump EBOOT_COMMIT to the merge SHA. Verified before pushing, master vs pin under the job's own configuration (-DEBLDR_BOARD=qemu_arm64 -DEBLDR_VERIFY_STAGE1=OFF -DCMAKE_BUILD_TYPE=Release, cross-compile mode): eBoot@master fails at the eos_image.h asserts, the exact error in the job log; eBoot@a172a6d builds every target, rc=0. Both pinned SHAs verified reachable from their repos' master. Workflow parses; the three `ref:` edits and the env block are the whole diff. This PR's own simulation run is the live test: it uses this branch's workflow and should go green while every master-based PR stays red. Carried onto this branch from #135 (001128d) so this PR's own simulation job runs against a buildable eBoot: each pull request executes its own copy of the workflow, so the fix greens a PR only once its branch contains it. Byte-identical to #135's commit -- git drops it as already-upstream the moment #135 merges. The pin itself is #135's to review.
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
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.
EoSim Sanityhas never had a green run in this repository. It is a nightly workflow, so it does not gate pull requests — it is simply red every morning.The cause
EOSIM_VERSIONis"0.1.0", andembeddedos-org/EoSimhas no such tag. Its tags runv1.0.0throughv3.0.1:The second message is a red herring that makes this look like an EoSim packaging problem. The directory is empty because the clone failed — EoSim is a perfectly normal Python project, and
v1.5.0carries apyproject.tomldeclaringname = "eosim"with a console entry point.Pinned to v1.5.0, the release marked Latest.
Verified, not assumed
I ran exactly what the workflow runs:
Those four are every EoSim command this workflow invokes.
One caveat worth recording
eosim listprintsAvailable platforms (0)whilediscover_platforms()on the same directory returns 149 — a display bug inside EoSim, not something this workflow can fix. It exits 0, so the sanity steps pass either way. Flagging it rather than leaving it to surprise the next person.