Keep an Anchor v1 copy of every Anchor example, tested in its own CI job

[mikemaccana]

Anchor v1 is expected to stay on long-term support, and many deployed programs will
stay with it. This ships both versions of every Anchor example, each built and tested
by its own CI job.

What is here

• 55 anchor-v1/ directories, one beside each anchor/, holding the example
  exactly as it stood before the v2 port. Restored from 94abbea, the last commit on
  main before that merge: 864 files, every blob byte-identical to the baseline.
• .github/workflows/anchor-v1.yml, building and testing them on Anchor 1.1.2.
• The existing workflow is now Anchor v2. Its filename, triggers and project
  discovery are unchanged.

The v2 directory keeps the plain name anchor/. No path in the current examples moves.

Notes for review

Repository size. 18 MB of files, but 16 MB of that is 17 third-party .so test
fixtures whose blobs are byte-identical to the ones already tracked under anchor/.
Git stores them once, so the tree actually grows by ~2.3 MB of text.

The two workflows cannot see each other's projects. Both discover work with
find -type d -name, which matches a path segment exactly — anchor never matches
anchor-v1 and vice versa. That also keeps anchor-example/ in the
nft-meta-data-pointer tree out of both, as before.

The v2-only IDL workaround is deliberately not carried into v1. anchor#4947
(enum variants emitted as "fields") is a 2.0.0-rc.1 bug, so v1 builds generate IDLs
normally rather than passing --no-idl.

The anchor-v1 crates are not root workspace members, and cannot be. Each carries
the same [package] name as its anchor/ sibling, and one workspace cannot hold two
packages called the same thing. Renaming them to *-v1 was considered and rejected: a
package-only rename still collides on the [lib] output filename (cargo warns
output filename collision, and says it may become a hard error), so it would mean
renaming 59 [lib] names, the target/deploy/<name>.so path that 56 test files
include_bytes!, 159 Anchor.toml [programs.localnet] keys and 62 declare_id! /
declare_program! sites — and the directories would stop being the programs as they
actually shipped on v1. The root Cargo.toml comment records this so the omission does
not read as an oversight.

The consequence is that cargo fmt and cargo clippy never see the v1 crates; the
Anchor v1 workflow compiles and tests them instead.

READMEs now name the CLI their commands need. A bare anchor build was unambiguous
while the repository had one Anchor and is not any more, so anchor/ pages say Anchor
v2 and anchor-v1/ pages say Anchor v1. README.md and CONTRIBUTING.md, which sit
above both, show both.

Both workflows now run weekly (v2 Mondays 03:00 UTC, v1 05:00 UTC, staggered). The
analyze step has always treated a scheduled run as "build everything", but nothing
declared a schedule, so that path had never executed. It is worth having because no
Anchor project commits a Cargo.lock and Dependabot only covers the root workspace, so
dependency drift in either tree is otherwise invisible until an unrelated PR happens to
touch those files.

Both Anchor jobs install the CLI from crates.io. The v1 job initially installed avm
from the tip of anchor's main branch, so what CI installed drifted with whatever
landed there. 1.1.2 is an ordinary published release, so it is now
cargo install anchor-cli --version 1.1.2 --locked, matching v2.

Verification

Checked locally before pushing:

• 55 projects discovered per workflow, with no overlap between them
• all 864 restored blobs byte-identical to 94abbea
• all 55 anchor-v1 projects resolve to their own workspace root, not the repository's
• no anchor-v1 crate entered the root workspace (cargo metadata: 0 of 101 members)
• cargo fmt --check clean; pnpm check exits 0 (94 warnings, all pre-existing — the
  v1 and v2 vault-strategy apps report an identical 47 each)
• five representative v1 projects compile against anchor-lang 1.1.2: favorites,
  escrow, token-extensions/basics, cutils, perpetual-futures
• every relative link in all 110 Anchor READMEs resolves on disk

Not verified locally: the LiteSVM tests include_bytes! a compiled .so, and the
container had no Anchor CLI or SBF toolchain, so anchor build / anchor test never
ran. CI is what proves those — and this first run builds all 55 v1 projects, because
the workflow file itself changed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BMDApPWRHM1StJwtyDSrEM

---

Generated by Claude Code