Add support to automatically update the "Stable tag" and "Tested up to" lines in the readme.txt during deployment.

[toolstack]

Description of the Change

Add support to automatically update the "Stable tag" and "Tested up to" lines in the readme.txt during deployment.

Closes #112

How to test the Change

Trigger a new deployment.

Changelog Entry

Added - Support for updating readme.txt "Tested up to" and "Stable tag" automatically as part of the deployment.

Credits

Props @toolstack

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• [] I have added tests to cover my change.
• All new and existing tests pass.

[jeffpaul]

In re-reviewing this, I don't think that our primary use case (or even an optional case here) would be to update the plugin source in GH from values on WP.org. I would expect that the values on GH should be updating WP.org (and not vice verse as I think this PR would do) and as such would recommend we close out this PR. @dkotter thoughts?

[dkotter]

In re-reviewing this, I don't think that our primary use case (or even an optional case here) would be to update the plugin source in GH from values on WP.org. I would expect that the values on GH should be updating WP.org (and not vice verse as I think this PR would do) and as such would recommend we close out this PR. @dkotter thoughts?

Yes, I agree with that and also agree with your initial comment here: #112 (comment). I think the most we should do here is have the deploy fail if the version number hasn't been bumped but I would not expect this action to automatically update that version and commit it back to GitHub.

[toolstack]

In re-reviewing this, I don't think that our primary use case (or even an optional case here) would be to update the plugin source in GH from values on WP.org. I would expect that the values on GH should be updating WP.org (and not vice verse as I think this PR would do) and as such would recommend we close out this PR. @dkotter thoughts?

This PR pulls the current WP version from WP.org (through the update api), and then updates GitHub before the push out to wp.org's plugin directory. This ensure that both GH and WP's repo's are up to date.

[toolstack]

Yes, I agree with that and also agree with your initial comment here: #112 (comment). I think the most we should do here is have the deploy fail if the version number hasn't been bumped but I would not expect this action to automatically update that version and commit it back to GitHub.

I'm fine with not merging this if it's considered out of scope for the action. I wouldn't want it to fail due to the non-updated value, that would seem heavy handed if the user wanted that to be the result (aka, perhaps the plugin doesn't work with newer versions of WP yet).

If the decision is to reject the change I'll fork the action (or maybe a separate action that just does the update) and release my own as I do think this is a useful feature to have.

[jeffpaul]

@toolstack that sounds reasonable to me, thanks!

[AlecRust]

I'll fork the action (or maybe a separate action that just does the update) and release my own

Just FYI there are existing actions that can do this, like mine 🙂

My personal preference here is to manage all three things separately, "Stable tag" as part of the release process (example) "Tested up to" as a PR that gets created, and the plugin deploy via this action. This action should just deploy imo.