Feat/add custom workspace

[Lewiscowles1986]

Requirements

Addresses #16 by re-approaching #30

Description of the Change

#16 is about having the code to push to the plugin repository in a separate folder to the git repo root.

This is a pattern I am familiar with through https://github.com/Lewiscowles1986/WordPressSVGPlugin

WordPress does not use or support Composer, so I ship my plugin with it's own autoloader and vendor folder.

I Like to keep the code separate to the vendor folder.

Also guards (WiP) the image subversion attribute change to cut down chatty logs

Alternate Designs

1. I could approach by asking myself and a number of other plugin authors to re-approach their repository design.
   • Means they would be shipping tests
   • Means any files in a repo, for it's release are shipped with plugins (I don't feel like this is ideal)
2. The PR at Add possibility to use custom workspace #30 is a slight variation of this one, where .wordpress-org (default asset folder), .gitattributes or it's analogue file are not part of the repo root either.
   • This seemed to be doing more than we had to.
   • This could result in confusion browsing repositories.
   • I can see why not all source code and files should be deployed.
   • I cannot see why moving all the conventional paths makes sense, and the concatenation of paths I could see causing problems

Benefits

• Less files to compress, push via SVN
• Developer freedom to support intricate build processes (Gutenberg plugins...)
• Simple environment variable

Possible Drawbacks

Technical complexity. A Thing is less easy to think about like this. People may enter paths that do not exist (possible future iteration).

Verification Process

I have not verified this, although I would be happy to think about how to do that. It's currently holding back a PR 😂

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

I would like help with these two if it is available... (I appeased shellcheck 😉 )

• I have added tests to cover my change.
• All new and existing tests passed.

https://github.com/Lewiscowles1986/WordPressSVGPlugin/runs/1294128965 shows this as working.

Applicable Issues

#16

Changelog Entry

• Added new ENV arg to re-target the plugin-directory base path WORKSPACE_DIR

[Lewiscowles1986]

Annoyingly this is not exporting my vendor folder (super annoying)

I have tried

• using sed to comment out the vendor folder from .gitignore
• committing the vendor folder to git in a similar way to .gitattributes using the -f flag to force adding...

[Lewiscowles1986]

This was used to deploy https://wordpress.org/plugins/enable-svg-uploads/#description using https://github.com/Lewiscowles1986/WordPressSVGPlugin/blob/main/.github/workflows/release.yml

Currently I'm fine using the fork, but ping if this is of interest, and I'll try to address any concerns.

There was a bit of pain in working out I need to git commit generated files from this action for example. This will impact anyone bundling vendor dependencies using composer and then adding to their SVN deploy step as it will not be included in git archive

[dinhtungdu]

At this point, we're in the $SNV_DIR, if $WORKSPACE_DIR is set to a relative path, this this command will fail.

[Lewiscowles1986]

This and my other PR have been working since 2020. Thank you for your input. I am closing this PR.