CI: install zeehio/BiocStyle@my-fixes consistently (pandoc + pkgdown fixes) - #83
Merged
Conversation
The "Install pkgdown" step reinstalled BiocStyle from the stale fix-biocstyle-with-pkgdown branch, overwriting the my-fixes install done earlier in the same job (which carries the pandoc >=3.8.1 uncaptioned-table counter fix) with a build lacking it. Both fixes (pandoc and pkgdown compatibility) now live on my-fixes, so install that branch in both places. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GXge48MtnR7KNWzCh34uAn
Verified empirically (simulating the "Install dependencies pass 2" step's remotes::install_local(upgrade = TRUE) against an already fork-installed BiocStyle) that it leaves an already-installed dependency alone once its version satisfies the requirement, regardless of source -- so the "defensive re-install" the previous commit added to the "Install pkgdown" step doesn't actually protect against anything. A single install, once, is sufficient; keep it in the unconditional "Install BiocStyle fork" step so it also covers non-devel/non-pkgdown CI runs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GXge48MtnR7KNWzCh34uAn
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.
Summary
zeehio/BiocStyle@my-fixesnow carries two critical fixes not yet merged upstream: the pandoc >=3.8.1 uncaptioned-table counter fix (already used in this workflow since #73) and a pkgdown-compatibility fix.What was wrong
check-bioc.ymlalready installedzeehio/BiocStyle@my-fixesearly in the job (the "Install BiocStyle fork" step). But the later "Install pkgdown" step (only run fordevelpushes) re-installed BiocStyle from a different, stale branch:That overwrote the earlier
my-fixesinstall — including the pandoc fix — with a build that doesn't carry it, right before the pkgdown site build step runs later in the same job. Historically these were two separate fork branches, each fixing a different problem, hence two install steps.Fix
Both fixes now live on the single
my-fixesbranch, so install it once, unconditionally, in the early "Install BiocStyle fork" step — which also means non-devel/non-pkgdown CI runs (PRs, other branches) get the pandoc fix too, not justdevelpushes.I initially pushed a version that installed the fork a second time in the "Install pkgdown" step "defensively," reasoning that the later "Install dependencies pass 2" step (
remotes::install_local(..., upgrade = TRUE)) might overwrite it with the official Bioconductor release. I verified that empirically instead of leaving it as a guess: I installed the fork locally, then ran the exact sameinstall_local(dependencies = TRUE, repos = gha_repos, upgrade = TRUE, force = TRUE)call against this repo and checkedpackageDescription("BiocStyle")afterward —RemoteTypestayed"local", unchanged.remotes'supgrade = TRUElogic compares version numbers, not install provenance, and since the fork'sDESCRIPTIONversion already satisfies the requirement, it's left alone. So the second install wasn't defending against anything and was removed.Testing
Verified locally (see above) that a
remotes::install_local(upgrade = TRUE)pass does not clobber an already-installed dependency whose version is already satisfied, regardless of source. Also validated the YAML parses correctly. No local run of the full workflow is possible (this only affectsdevel-branch and PR CI runs), but this repo's existing CI will exercise it once merged.