Skip to content

fix: rename from the provider's current name, so a renamed provider's CI passes - #3

Merged
CameronBrooks11 merged 1 commit into
mainfrom
fix/rename-from-current-name
Nov 5, 2026
Merged

CameronBrooks11 merged 1 commit into
mainfrom
fix/rename-from-current-name

Conversation

@CameronBrooks11

Copy link
Copy Markdown
Member

scripts/rename.sh hardcoded the template's name and skipped rewriting itself. So after the first rename it still renamed from anolis-provider-template-python, and the second run failed. The "Rename still builds" CI job runs exactly that second rename in every provider made from the template, so every such provider went red right after following the README's step 2. Found by the outside instance, CameronBrooks11/anolis-provider-hello-python:

fatal: bad source, source=src/anolis_provider_template_python, destination=src/anolis_provider_renamed_check

The fix:

  • rename.sh reads the current name from pyproject.toml's project name, so it renames from whatever the provider is called now.
  • The CI rename job now renames twice, so this class of bug fails here in the template rather than in a provider made from it.

Verification

  • In a scratch copy, renamed template → hello-python → renamed-check: both runs exit 0, no file names either earlier name, and format, lint, mypy and all 7 tests (harness included) pass.
  • The old script, on the same second rename, fails as quoted above (hello-python's CI run on 1ca8b57).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant