🚨 Fix develop-sources include path (anchor at GITHUB_WORKSPACE) — unbreaks monorepo sublibrary CI

[ChrisRackauckas-Claude]

🚨 Urgent — fixes a regression that broke all monorepo sublibrary CI

The develop_sources extraction in #98 (released in v1.15.1) introduced a step that fails for every monorepo, e.g. ModelingToolkit Sublibrary CI:

ERROR: LoadError: SystemError: opening file
  "/home/runner/work/_temp/.sciml-dotgithub/scripts/develop_sources.jl": No such file or directory

Root cause

The "Develop in-repo [sources]" step uses shell: julia --color=yes {0}. GitHub writes the step body to a temp file under RUNNER_TEMP and runs it from there. Julia's include resolves a relative path against the including file's directory (RUNNER_TEMP), not GITHUB_WORKSPACE — where actions/checkout placed .sciml-dotgithub. So include(joinpath(".sciml-dotgithub", …)) looked in RUNNER_TEMP/.sciml-dotgithub and missed.

Only monorepo sublibrary jobs hit it — the step is gated on inputs.project != '.' && '@.', so plain-repo CI (which skips the develop step) was unaffected. That's why it surfaced as broken Sublibrary CI across MTK/Optimization/etc. right after the v1.15.1 retag.

Fix

Anchor the include at ENV["GITHUB_WORKSPACE"]:

include(joinpath(ENV["GITHUB_WORKSPACE"], ".sciml-dotgithub", "scripts", "develop_sources.jl"))

Verification

Simulated the exact step (a Julia temp-script in RUNNER_TEMP, run from a third cwd, with .sciml-dotgithub under GITHUB_WORKSPACE):

• the relative form reproduces the SystemError verbatim;
• the GITHUB_WORKSPACE-anchored form loads develop_sources cleanly (isdefined → true).

tests.yml passes yaml.safe_load. (The #98 unit test exercised develop_sources.jl as a function, not the workflow's include, which is why this slipped through.)

⚠️ Needs a v1 retag

Consumers pin @v1, so this only takes effect after merge and a v1 retag. Until then, all monorepo sublibrary CI stays broken — please fast-track.

---

🤖 Generated with Claude Code

Please review ASAP — @ChrisRackauckas.