Summary
On the first release of an approved WordPress.org plugin, publishing from an SVN checkout root fails while setting MIME types when directory assets already live in the standard sibling assets/ directory.
Pressship discovers the plugin in trunk/, so rootDir is the trunk directory. syncAssets() consequently looks only for trunk/.wordpress-org. When that directory is absent, assetFiles is empty and the existing sibling assets/* files are never passed to svn add. setAssetMimeTypes() then finds those physical files and tries svn propset, which fails because they remain unversioned.
Environment
- Pressship 0.2.2 via
npx pressship
- macOS
- Fresh WordPress.org SVN repository with empty
trunk/, tags/, and assets/
- Plugin runtime copied into
trunk/
- WordPress.org listing images copied into sibling
assets/
Reproduction
- Check out an approved, not-yet-released plugin SVN repository.
- Put the validated plugin package in
trunk/.
- Put PNG/SVG listing assets directly in sibling
assets/.
- Run
npx pressship publish <svn-root> --release -y.
The release reaches:
Creating tag 0.5.9
A tags/0.5.9
...
assets/banner-1544x500.png is not under version control
svn: E155010: The node .../assets/banner-1544x500.png was not found.
svn propset svn:mime-type image/png assets/banner-1544x500.png failed.
svn status shows every sibling asset as ?, while trunk and the tag are scheduled for addition.
Expected
For an SVN-root release, Pressship should either:
- recognize and add files already present in the sibling
assets/ directory, or
- require/copy a declared asset source before attempting MIME properties.
It should not attempt svn propset on unversioned files.
Retry problem
The failed attempt leaves tags/<version> scheduled locally. A retry then stops at assertReleaseVersionIsNew() because it checks filesystem existence, reporting that the version already exists in WordPress.org SVN even though no commit occurred and the remote tag is absent. Checking the remote/versioned state, or cleaning the failed scheduled tag, would make recovery possible.
Confirmed workaround
Creating trunk/.wordpress-org from the sibling assets and publishing with --ignore ".wordpress-org/**" causes Pressship to add the sibling assets before setting MIME types. This confirms the failure is asset-source discovery/order, not SVN permissions or the files themselves.
Summary
On the first release of an approved WordPress.org plugin, publishing from an SVN checkout root fails while setting MIME types when directory assets already live in the standard sibling
assets/directory.Pressship discovers the plugin in
trunk/, sorootDiris the trunk directory.syncAssets()consequently looks only fortrunk/.wordpress-org. When that directory is absent,assetFilesis empty and the existing siblingassets/*files are never passed tosvn add.setAssetMimeTypes()then finds those physical files and triessvn propset, which fails because they remain unversioned.Environment
npx pressshiptrunk/,tags/, andassets/trunk/assets/Reproduction
trunk/.assets/.npx pressship publish <svn-root> --release -y.The release reaches:
svn statusshows every sibling asset as?, while trunk and the tag are scheduled for addition.Expected
For an SVN-root release, Pressship should either:
assets/directory, orIt should not attempt
svn propseton unversioned files.Retry problem
The failed attempt leaves
tags/<version>scheduled locally. A retry then stops atassertReleaseVersionIsNew()because it checks filesystem existence, reporting that the version already exists in WordPress.org SVN even though no commit occurred and the remote tag is absent. Checking the remote/versioned state, or cleaning the failed scheduled tag, would make recovery possible.Confirmed workaround
Creating
trunk/.wordpress-orgfrom the sibling assets and publishing with--ignore ".wordpress-org/**"causes Pressship to add the sibling assets before setting MIME types. This confirms the failure is asset-source discovery/order, not SVN permissions or the files themselves.