Option for a trunk-only deployment

[johnbillion]

Is your enhancement related to a problem? Please describe.

I'd like to be assured that a deployment to wordpress.org is as expected before tagging it.

Describe the solution you'd like

If it was possible to perform a trunk-only release via this action, I could then verify the changes in the trunk branch are expected before triggering a regular release which creates the tag.

It would be neat if this action supported a configuration environment variable that instructed it to only deploy the changes to trunk, without also copying them to the tag. It would need to be possible to perform a subsequent release to the tag without it being skipped due to no changed files, so maybe two vars are needed such as NO_TRUNK and ONLY_TRUNK.

[jeffpaul]

An interesting idea, though admittedly not likely something I would look to spend much time on building out, so if that's something you would want to contribute then I would at least look to help with code review, merge, and future support/maintenance.

[danieliser]

I think another option here would be adding an additional output changed-files, that works with both dry-run enabled or disabled. This could then be piped into any other action.

Like @johnbillion I want validation I'm not pushing a broken build some times.

Current workaround is to on creation of draft release we build a zip and attach it to the release, but also run deploy action on dry-run. I'd love to not have to manually check it in the action logs, but its just one more safety net.

[kasparsd]

Came here looking for this feature.

WP-org allows pushing readme.txt updates for Tested up to to trunk only without having to do a release.

Secondly, it would be useful to have the development version of the plugin available at trunk to allow for testing while still hosting the release ZIP on WP-org.

[peterwilsoncc]

Coming back to this, I'm more than a little hesitant to add this feature to the action.

The plugin handbook includes the warning "SVN and the Plugin Directory are a release repository. [...] Please only push finished changes to your SVN repository".

I'm concerned that introducing this feature would encourage people to push each commit to the WordPress.org repo and go against that request. This could happen without intent with some basic misconfiguration or misunderstanding.

---

WP-org allows pushing readme.txt updates for Tested up to to trunk only without having to do a release.

@kasparsd For this use case, please use the https://github.com/10up/action-wordpress-plugin-asset-update action. It allows for readme and plugin repo assets to be updated between releases.

[kasparsd]

Thanks for the action-wordpress-plugin-asset-update recommendation -- I wasn't aware it existed. That definitely solves for doing the asset and readme pushes on branch updates.

I'm concerned that introducing this feature would encourage people to push each commit to the WordPress.org repo and go against that request.

This would be an opt-in feature so users would have to make the choice to do that. I would assume that most people would happily use the defaults which is tag deployments and the branch-only is just a useful feature for those who need it.

In practice most projects use pull requests for the actual development and pushes to main/trunk happen only when the pull requests (new features, bug fixes) are merged in so this would mean that only "finished changes" are pushed to trunk. Overall, deployments to SVN trunk are a valid deployment process and it would be useful if this action supported that.

[peterwilsoncc]

This would be an opt-in feature so users would have to make the choice to do that.... In practice most projects use pull requests...so this would mean that only "finished changes" are pushed to trunk.

Even so, it would allow developers to go against the WordPress.org plugin (and I presume systems) team request that only releases be pushed to the plugins svn repo.

I don't want to encourage that by making it a one liner to do so. Depending on how strict WP.org are about this, it could result in difficulties for plugin developers.

The deploy code is open source so I think plugin authors wishing to go against the request of the plugin/systems team should do so in full in their own repos.

Having considered this further overnight, I'm going to close this issue as unplanned.