Skip to content

Add project structure, configuration, and template sync workflow#4

Open
sbglasius wants to merge 15 commits into
mainfrom
feature/pull-request-functionality
Open

Add project structure, configuration, and template sync workflow#4
sbglasius wants to merge 15 commits into
mainfrom
feature/pull-request-functionality

Conversation

@sbglasius

Copy link
Copy Markdown
Collaborator

Re-rolled this PR (from #2). Should be merged after #3

This pull request adds two new comprehensive documentation files to the .agents/skills directory. These documents provide detailed, step-by-step guides and best practices for (1) migrating a Grails plugin repository to the standardized template structure, and (2) organizing and testing example applications under the examples/ directory. These guides are intended to help maintainers modernize plugin repositories and ensure consistent, effective integration and functional testing.

Enhance Plugin with Template Structure:

  • Introduces a complete migration playbook for converting an existing Grails plugin repository to the grails-plugin-template structure, covering prerequisites, file organization, build configuration, metadata management, documentation, and common pitfalls.

Example Application Best Practices:

  • Documents best practices for creating and maintaining example applications under examples/, including project structure, dependency management, integration test organization, and recommended patterns for testing plugin behavior as a real consumer.

sbglasius and others added 13 commits May 13, 2026 15:08
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Missing codestyle and codecoverage added, fixing codenarc violations
* correct plugin test task path and load project metadata in docs build
* allow publish jobs for both grails-plugins and gpc orgs
* Potential fix for pull request finding
* correct contributor name typo and duplicated wording in docs
* correct typo in documentation URL (templatae -> template)
- Add .github/workflows/files-sync.yml: syncs infrastructure files to
  registered plugin repos on release, using a GitHub App for cross-org
  write access (gpc + grails-plugins)
- Add .github/scripts/prepare-sync-matrix.groovy: builds GH Actions
  matrix from .github/projects.yml
- Add .github/projects.yml: registry of target repos for the sync
- Add TEMPLATE_README.md: guide for new plugins and migration path
- Prepend "do not edit" warning comments to all synced files
  (workflows, scripts, build-logic convention plugins)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
update-versions.yml falls back to github.ref_name when no branch
input is given, which on pull_request events resolves to the
merge-ref pseudo-name (e.g. "16/merge") instead of a real branch,
causing actions/checkout to fail. Pass github.head_ref explicitly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
update-versions.groovy exits early without generating build/ghpages.html
when no versioned directories exist yet on gh-pages (e.g. a repo that
has only published snapshot/latest but no numbered release). The push
step assumed the file always existed and failed the job with
"cannot stat 'build/ghpages.html'".

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
update-versions.groovy previously skipped generating ghpages.html
entirely when gh-pages had no versioned directories yet, which broke
the push step for plugins on the new build structure that have only
published a snapshot. Now it still builds the index, omitting the
"Latest Release" and "Other Versions" sections (via a HAS_VERSIONS
template flag) until an actual release is published.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GitHub Pages only auto-serves index.html for a directory, so the
generated version-index page as "ghpages.html" was never actually
reachable at the gh-pages root.

Also, "git diff --quiet ghpages.html" without --cached only reports
changes to already-tracked content; for a repo whose gh-pages branch
has never had a root index file (e.g. only snapshot/ so far), the new
file is untracked and git diff reports no difference at all, so the
push step silently skipped committing it. Stage the file first, then
check "git diff --cached --quiet" so new files are detected too.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…/skills

Adds a new SKILL.md distilled from the real grails-jasypt migration
(chore/prepare-release), documenting the phases and pitfalls of moving
an existing Grails plugin onto this template's structure. README.md
and TEMPLATE_README.md now document what plugin-specific values need
changing when adapting the template.

Also generalizes .skills/ to .agents/skills/, with .claude symlinked to
.agents for Claude Code discovery, and converts each flat skill doc
into the skills/<name>/SKILL.md layout with frontmatter so agents can
discover them. Updates files-sync.yml, AGENTS.md, CONTRIBUTING.md, and
the migration skill's own references accordingly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@sbglasius sbglasius requested a review from jdaugherty July 7, 2026 17:23
sbglasius and others added 2 commits July 8, 2026 16:04
Repository-level Actions secrets take precedence over org-level ones
of the same name. A plugin migrated into gpc/grails-plugins may still
carry its own SIGNING_KEY/SECRING_FILE/NEXUS_PUBLISH_* secrets from
before the move, silently shadowing the org's shared credentials and
causing a confusing signing failure on the first real release — as
happened with grails-jasypt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
github.run_id stays constant across a "re-run failed jobs" on the
same workflow run. If an earlier attempt created and described a
Sonatype staging repo before failing, a retry created a second repo
with an identical description, and findSonatypeStagingRepository then
refused to pick one ("Too many repositories found"). Append
github.run_attempt, which does increment on a re-run, to
NEXUS_PUBLISH_DESCRIPTION in both the publish and release jobs so each
attempt gets a distinguishable description.

Also documents the incident in the enhance-plugin-with-template
skill, including that Sonatype's Central Portal "Deployments" UI and
the legacy ossrh-staging-api.central.sonatype.com staging API are
different backends that don't share state.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.

2 participants