Repository navigation
Fix the PlatformIO platform reference, drop maintainer process from R… - #1
Merged
Merged
Conversation
…EADME The CH32V platform is community-maintained and is not in the PlatformIO registry, so "platform = ch32v" resolves only on a machine where it already happens to be installed. A clean checkout fails with UnknownPackageError, which is what CI hit on its first run -- so the quickstart in the README was broken for exactly the new users it targets. Both the README and the example now give the platform by URL. Also removes the contributing and releasing sections. Branch protection and release mechanics are maintainer process; they tell someone evaluating the library nothing. The workflow file already documents its own behaviour.
The CI step ran "pio run -d examples/pio_ticker_blink", which failed because the example declared no lib_deps and PlatformIO does not resolve a library from the enclosing directory. The comment in that file claiming otherwise was wrong, and the step had never been run before it was written. Giving the example "lib_deps = fyfar/Ticker" makes it build, and makes it a genuine standalone project users can copy. But it also means building it resolves Ticker from the registry, so CI would compile the already-published version and pass even if a pull request broke src/ entirely. Confirmed: with a #error added to src/Ticker.h, "pio run -d examples/pio_ticker_blink" still reported SUCCESS. Overriding PLATFORMIO_LIB_DEPS did not help; it also passed. So the working tree is built with "pio ci --lib=.", which does fail on that same #error. The second step keeps building the example the way a user gets it, since "the shipped platformio.ini works standalone" is a separate claim and is exactly what broke here. All four CI steps were run locally before this commit.
pio ci validates --board against the platforms already installed, and does so before installing anything, so genericCH32V003F4P6 is an unknown board ID on a clean machine. Local runs never showed this because the platform was already installed there. Validated this time against an empty PLATFORMIO_CORE_DIR rather than the local one, which is what a runner actually starts from. All four build steps pass there. The platform install also brings the RISC-V toolchain, so the Makefile step still has what it needs.
The compiler PlatformIO ships is riscv-none-embed-gcc on macOS but not on Linux, so a hardcoded prefix builds locally and fails on the runner. Deriving it from whichever gcc is actually present makes the step host-independent. The previous clean-installation check could not have caught this: that was a missing-state problem, this is a host difference, and the local host is macOS.
push was filtered to main, so a commit on a feature branch with no pull request open built nothing. It now matches every branch, but deliberately not tags: the publish job pushes vX.Y.Z, which would otherwise start a second build for a ref that can never publish. With push covering every branch, a pull request from a branch in this repository would build the same commit twice, so build takes the push run for those and keeps the pull_request trigger for forks, which never produce a push event here. Publishing is unchanged and already met the requirement: push, on main, and gated on library.json naming a version the registry does not have.
Reverts the every-branch push trigger. push is back to main only, so a merge still builds and can publish, and pull_request covers the work leading up to it, whatever branch it targets. That also removes the reason for the dedup guard on the build job, and with it an ambiguity it introduced: with both triggers firing on one commit, a pull request ended up with two checks of the same name, one skipped and one successful, which is a poor thing for branch protection to have to interpret. pull_request types are listed explicitly. synchronize is the one that fires on every new commit pushed to an open pull request, so updating a pull request rebuilds; that is a requirement here, not an incidental default.
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.
…EADME
The CH32V platform is community-maintained and is not in the PlatformIO registry, so "platform = ch32v" resolves only on a machine where it already happens to be installed. A clean checkout fails with UnknownPackageError, which is what CI hit on its first run -- so the quickstart in the README was broken for exactly the new users it targets. Both the README and the example now give the platform by URL.
Also removes the contributing and releasing sections. Branch protection and release mechanics are maintainer process; they tell someone evaluating the library nothing. The workflow file already documents its own behaviour.