Deploy a specific directory within repository

[mauryaratan]

Describe your question

Wondering if it is possible to make this action deploy from a specific directory which is being created by npm task. Say build/plugin-slug.

Based on docs, if I changed the directory with working-directory keyword within workflow, would that work as expected?

[helen]

I'm sure it's possible but I don't know yet if this is a direction I'd like this action to take. The docs you linked are describing directly running a command in a directory and does not impact this actual action, which does some directory changes anyway.

Can you describe what you're doing that the build is located in a subdirectory like that?

[sery0ga]

@helen I have a similar question. I have a Github repository and the plugin's code is in the subdirectory of this repository. And I would like to keep it this way because there is some supportive code I see no reason to push to WordPress servers.

It would be awesome if I could set a new env variable with the directory of the plugin. Maybe, it is possible?

[sery0ga]

@helen if I understand the code correctly, it could be done something like this:

`
if [[ -z "$PLUGIN_DIR" ]]; then
PLUGIN_DIR=""
fi

....

rsync -rc "$TMP_DIR/$PLUGIN_DIR/" trunk/ --delete
`

[mauryaratan]

@helen It's just how my workflow is laid out. I usually keep the build directory separate from working directory. And this is something I do quite often.

It'd be grreat if @sery0ga's suggestion could make it in.

[marcospassos]

Same issue here.

[ssnepenthe]

@helen I know this is an old issue but wanted to chime in with another scenario to consider.

I am looking at using PHP-Scoper so I can include third party packages without having to worry about conflicts.

As far as I can tell there doesn't seem to be much consensus on the best way to use PHP-Scoper in a WordPress plugin - I have seen wildly different approaches in plugins like wordpress-seo and google-site-kit.

But by default (the way I have set it up so far) it creates a "build" subdirectory which contains a complete scoped version of the plugin that is ready to deploy.

I don't know yet if this is a direction I'd like this action to take.

Have you had any new thoughts on whether this is something you would like to support going forward?

[jeffpaul]

@dinhtungdu @iamdharmesh its worth chatting about the separate approaches for this in #30 and #56, to see which approach might be most optimal (or if a third option might be better).

[dinhtungdu]

@jeffpaul between #30 and #56, I'm leaning towards the latter one. But I have an issue with both PRs: if the plugin files are built into a custom folder, then we don't need the ignore files because all files in that custom folder are meant to be deployed.

IMO, we should treat the custom build folder as a separate scenario instead of the way those two PRs are doing. Because of that, I'm not really convinced by any of those PRs. I'll work on a PR this week to demonstrate my idea.