Plugin Deploy: Configurable excludes?

[helen]

Currently the plugin deploy script excludes the .git and .github directories because, well, they aren't needed. The plugin deploy action is really meant to be used together with the planned build process action, which means that other extraneous files shouldn't be lying around anyway, but I'm opening this issue just to track the idea in case we feel it would be a good thing for the deploy action to have configurable excludes.

Technically speaking, this is probably a matter of --exclude-from and an ENV variable to override the default. Would need to test to be sure that can be used in conjunction with --exclude which is used for the assets directory (already configurable).

[johnbillion]

Separating the build process from the deployment process is definitely a good idea, as they're two distinct actions and can be performed and used independently of one another. For example, I might want to use my existing grunt/gulp/bash/webpack build process that I've spent years fine-tuning, and just hook up its output to an action that performs the deployment to w.org.

If a separate build action is developed then it would be a good idea to make use of existing methods of file exclusion (most of which use glob patterns) such as .gitattributes (with export-ignore flags), .distignore, .deployignore, .gitignore, and maybe even the archive.exclude property in a composer.json file.

[tnorthcutt]

Agreed it'd be nifty to discover existing ignore methods, especially .distignore since I'm guessing many plugins might already be using wp dist-archive in their build-for-dotorg-repo process.

Would also seem perfectly reasonable to allow an action-specific ignore file, e.g. deploy-ignore or something similar. My gut reaction is that a file for listing ignores would be preferable to configuring via a flag, since the file then gets tracked in git.

[helen]

@johnbillion @tnorthcutt Opened an issue to document my thoughts and discuss the build action in #3 :)

[helen]

I'm revisiting this as I add an Actions workflow to a plugin that currently keeps the built files in develop (will likely change this soon but not right now) so I don't want to do the build step as an Action at the moment but I do want to exclude some more files from deployment. I'm a bit torn about which technical method to go with/support. Perhaps the easiest route for now would be to use .gitattributes + git archive and explore further later? I want to look into whether I could copy a default .gitattributes file into place to be used if there isn't one so certain things are excluded no matter what (as they are now). I also don't know if this affects GitHub's ZIP archives, although I assume it does.

@johnbillion Any thoughts?

[johnbillion]

My preference is to use .gittattributes because that's what git archive respects, which in turn is used by several distribution mechanisms such as GitHub's ZIP files and Packagist for Composer dependencies.

At least one of my plugins has a build step which is run by Grunt and that command also respects the contents of gitignore and .gitattributes. See https://github.com/johnbillion/query-monitor/blob/79658764b385b3248ccce0a1ae408ce9b943c24a/Gruntfile.js#L7-L14 and https://github.com/johnbillion/query-monitor/blob/79658764b385b3248ccce0a1ae408ce9b943c24a/Gruntfile.js#L74-L75

A default .gitattributes makes sense, we're looking at doing just that for the WP-CLI command packages: wp-cli/wp-cli#5070 (comment)

[helen]

I did finally remember part of why I went with rsync originally - being able to exclude the configurable $ASSETS_DIR (along with the very convenient --delete option). I think it's fine to change this up because the benefits outweigh requiring people to do a little more work to use a non-default assets directory, just wanted to document my thought process.