The release of v0.1.0 (merged PR 13) failed at the Composer registry step: Gitea answered 400 composer.json file is missing. The shopware-cli zip wraps everything in a top-level folder; Gitea needs composer.json at the zip root. (The release and tag v0.1.0 and its asset were created; only the registry upload and package link are missing for that version.)
Changes
release.yml: repack the same prebuilt zip root-level for the Composer registry upload (the GitHub-style Release asset stays the shopware-cli zip). Steps are now idempotent (existing release/asset reused, registry 409 = published) and the "tag exists -> skip" guard is removed, so a failed run can be re-run to completion.
Docs:CLAUDE.md (PHP ^8.2, real admin module, CI/release section) and the compliance spec refreshed after PR 13.
Tests: unit tests asserting CreateDumpHandler and DumpService::delete log to the injected PSR logger (not yet run; CI is the first run).
Version 0.1.1 + changelog (required by the PR check).
Not verified
The repack step has only been checked by reading; the first real run is this PR's merge.
New tests have never been executed (mock signatures copied from src/).
Gitea's registry answered 400 'composer.json file is missing' for the shopware-cli zip
(single top-level folder). Repack the same prebuilt content with composer.json at the root.
Drop the tag-exists skip guard so a half-finished release can be re-run; reuse an existing
release/asset. Bump to 0.1.1.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The repack step builds the archive with zip -qr "$OUT" ., which stores entries with a ./ prefix (e.g. ./composer.json). The following check unzip -l "$OUT" | grep -E ' composer\.json$' therefore does not match and the step exits with an error, so the release workflow will fail on the first real run. The check should match a root-level ./composer.json entry.
- name:Repack the zip for the Composer registryrun:| set -e
rm -rf /tmp/repack && mkdir /tmp/repack
unzip -q ".build/${{ steps.meta.outputs.zip }}" -d /tmp/repack
if [ -f /tmp/repack/composer.json ]; then
ROOT=/tmp/repack
else
ROOT=$(find /tmp/repack -mindepth 1 -maxdepth 1 -type d | head -1)
fi
test -f "$ROOT/composer.json" || { echo "::error::no composer.json found in the packaged zip"; exit 1; }
OUT="$PWD/.build/composer-${{ steps.meta.outputs.zip }}"
(cd "$ROOT" && zip -qr "$OUT" .)
unzip -l "$OUT" | grep -E ' composer\.json$' > /dev/null || { echo "::error::repacked zip has no root-level composer.json"; exit 1; }
echo "repacked: $OUT"
## PR Reviewer Guide 🔍
<!-- pr-agent:review:full -->
Here are some key observations to aid the review process:
<table>
<tr><td>⏱️ <strong>Estimated effort to review</strong>: 3 🔵🔵🔵⚪⚪</td></tr>
<tr><td>🧪 <strong>PR contains tests</strong></td></tr>
<tr><td>🔒 <strong>No security concerns identified</strong></td></tr>
<tr><td>⚡ <strong>Recommended focus areas for review</strong><br><br>
<details><summary><a href='https://git.arthurerlich.de/haylan/AeonDumpManager/src/branch/fix/release-registry-zip/.gitea/workflows/release.yml#L117-L131'><strong>Repack validation</strong></a>
The repack step builds the archive with `zip -qr "$OUT" .`, which stores entries with a `./` prefix (e.g. `./composer.json`). The following check `unzip -l "$OUT" | grep -E ' composer\.json$'` therefore does not match and the step exits with an error, so the release workflow will fail on the first real run. The check should match a root-level `./composer.json` entry.
</summary>
```yaml
- name: Repack the zip for the Composer registry
run: |
set -e
rm -rf /tmp/repack && mkdir /tmp/repack
unzip -q ".build/${{ steps.meta.outputs.zip }}" -d /tmp/repack
if [ -f /tmp/repack/composer.json ]; then
ROOT=/tmp/repack
else
ROOT=$(find /tmp/repack -mindepth 1 -maxdepth 1 -type d | head -1)
fi
test -f "$ROOT/composer.json" || { echo "::error::no composer.json found in the packaged zip"; exit 1; }
OUT="$PWD/.build/composer-${{ steps.meta.outputs.zip }}"
(cd "$ROOT" && zip -qr "$OUT" .)
unzip -l "$OUT" | grep -E ' composer\.json$' > /dev/null || { echo "::error::repacked zip has no root-level composer.json"; exit 1; }
echo "repacked: $OUT"
```
</details>
</td></tr>
</table>
- resolve the latest 6.6.x from Packagist; cache key shopware-<version>-installed-v1
- cache the project plus a SQL dump of the installed shopware_test database; on a hit restore
the dump instead of running system:install (~4.6 min)
- rename the step 'Install Shopware (once)' to 'Install Shopware'
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- phpunit: 'Resolve the latest Shopware Version' uses composer show against require.shopware/core
from the plugin's composer.json (the Packagist scrape returned nothing on the first run)
- release: build the registry zip from an explicit file list without a leading ./ so the
composer.json entry is stored at the zip root
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- composer.json 0.0.6, CHANGELOG entries of the withdrawn 0.1.0/0.1.1 merged into [0.0.6]
- version-changelog: version must exceed the latest published release (main may carry a
version whose release was withdrawn), instead of exceeding main's version
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
haylan
scheduled this pull request to auto merge when all checks succeed 2026-10-03 23:19:58 +00:00
haylan
merged commit 1176d3c87d into main2026-10-03 23:21:08 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
User description
Why
The release of v0.1.0 (merged PR 13) failed at the Composer registry step: Gitea answered
400 composer.json file is missing. Theshopware-clizip wraps everything in a top-level folder; Gitea needscomposer.jsonat the zip root. (The release and tagv0.1.0and its asset were created; only the registry upload and package link are missing for that version.)Changes
shopware-clizip). Steps are now idempotent (existing release/asset reused, registry 409 = published) and the "tag exists -> skip" guard is removed, so a failed run can be re-run to completion.CLAUDE.md(PHP^8.2, real admin module, CI/release section) and the compliance spec refreshed after PR 13.CreateDumpHandlerandDumpService::deletelog to the injected PSR logger (not yet run; CI is the first run).Not verified
src/).🤖 Generated with Claude Code
PR Type
Bug fix, Tests, Documentation
Description
Repack release zip root-level for registry
Make release workflow steps idempotent
Add PSR logger unit tests
Bump version and refresh docs
Diagram Walkthrough
File Walkthrough
3 files
Add CreateDumpHandler PSR logging testsAdd DumpService delete logging testsAdd PSR logger test double1 files
Repack zip and make release idempotent3 files
Add version 0.1.1 release notesDocument admin module and CI releaseUpdate compliance spec after pipeline run1 files
Bump plugin version to 0.1.1PR Reviewer Guide 🔍
Here are some key observations to aid the review process:
Repack validation
The repack step builds the archive with
zip -qr "$OUT" ., which stores entries with a./prefix (e.g../composer.json). The following checkunzip -l "$OUT" | grep -E ' composer\.json$'therefore does not match and the step exits with an error, so the release workflow will fail on the first real run. The check should match a root-level./composer.jsonentry.PR Code Suggestions ✨
No code suggestions found for the PR.