10up / action-wordpress-plugin-deploy Goto Github PK

The project I use needs to send the vendor folder that is generated by the composer to Wordpress's SVN.

I run the composer install according to your read.me, but apparently it does this before creating the SVN folder and therefore the files are not uploaded.

Here is the link to my configuration file:
https://github.com/Frete-Click/WooCommerce/blob/master/.github/workflows/wordpress-svn-deploy.yml

@helen @jeffpaul We receive SVN commit failed: Directory out of date issue recently. You can see this failed action https://github.com/themegrill/suffice-toolkit/runs/3016789941?check_suite_focus=true#step:5:269

Describe the bug

Probably GitHub has updated their docs and the Secrets are set in your repository settings link present on the README.md file points to the wrong page.

Steps to Reproduce

1. Go to repo's README.md
2. Click on Secrets are set in your repository settings.
3. The link points to the Virtual environments for GitHub-hosted runners page but the related section isn't there anymore :(

Expected behavior

The link should point to this new page.

Hey, I'm trying to deploy a plugin with a build process with composer install, npm install and webpack. When I tried deploying the plugin to w.org, it first failed because I didn't have a .git directory (I removed it during the build process).

I think this action is somehow tied to the git tag.

After I added the .git folder back, the deployment was successful but it deleted all my build files from the SVN repo, such as composer dependencies, javascript and css files. Needless to say this rendered the plugin non-functional.

I think the action is somehow tied to how git tracks the files, because my build files were not under git and they were removed.

The documentation here talks a lot about excluding files but not including them. Is it possible to use this action to deploy files that are not in the git repository?

Thanks!

We do not include languages/<plugin-name>.pot within git repository due to merge conflicts received time and again but auto generates them with the command npm run build which also executes wp i18n command during the build. How to execute composer script during the build action and add those files for the GitHub action?

Ref: https://github.com/wpeverest/everest-forms/blob/develop/package.json#L13

Describe the bug
.wordpress-org, .github, and .gitattributes have been uploaded to SVN.

• Setting .gitattributes file.
  https://github.com/tkc49/kintone-form/blob/master/.gitattributes

• Target repository.
  https://wordpress.org/plugins/kintone-form/

I'm trying to deploy my plugin on SVN but it is giving me this "##[error]Docker run failed with exit code 1" error. Below is the Repo URL:
https://github.com/mobeenabdullah/WP-Select-Primary-Category/

Below is the error details in the screenshot URL:
https://ibb.co/JmxpzTv

Waiting for the kind help.

Best,
Mobeen A.

Is your enhancement related to a problem? Please describe.
With the new .distignore method of excluding files from deployment, the GitHub-generated ZIP file attached to releases no longer reflects what gets deployed to .org. Also, broadly that automatic naming is an issue, as you'll get plugin-slug-X.Y.Z as the folder name upon unzipping, which is not really what you or WordPress want.

Describe the solution you'd like
Test additional steps in a test repo workflow and then add them to README.md. My sense is that existing Actions can be leveraged to generate the ZIP and attach it to a release, but don't know yet. If not, we can write one, which will also be useful for plugins that don't release to .org at all and update directly from GH instead.

This might be a silly question, but I'm setting this up for the first time and want to make sure I'm doing it right.

Let's say I'm developing a new version in a release/2.0 branch.

When my new version is ready, should I:

a) Merge release/2.0 with master, and tag a new version from master
b) Tag a new version from my release/2.0 branch, and then merge with master once the

I have the assets action set up as well, so I'm trying to figure out which way is preferable without causing conflicts.

Thanks!

Is your enhancement related to a problem? Please describe.
When developing a plugin on GitHub, it's not uncommon to tag pre-releases (like beta and release candidates). Those tags would also trigger a deployment on the plugin directory.

Describe the solution you'd like
The action currently runs on all tags. With a simple addition, which excludes all tags with a suffix (e.g. 2.0.0-beta, 2.0.0-RC1, etc.) such pre-release tags would not trigger the action.

name: Deploy to WordPress.org
on:
  push:
    tags:
    - "*"
    - "!*-*"
...

Additional context
This change can be done without chaning the files of the actions, it should only be added to the README of this repo.

Is your enhancement related to a problem? Please describe.
It's not obvious the level of support provided for this repo, so let's add some clarification.

Describe the solution you'd like

• add support level section and badge
• add release version badge
• add license badge
• create CHANGELOG.md

Designs
n/a

Describe alternatives you've considered
none

Additional context
n/a

Describe your question
I have a plugin that uses a PSR-4 autoloader. Currently, I have the vendor folder unignored and committed to the repo.

I would like, however, to be able to ignore the vendor folder and adjust the deploy process to run composer install --no-dev before actually packaging the ZIP to be sent to WordPress.org.

Problem is, I'm not sure how to accomplish this. Can you help me?

This is my workflows folder, for reference: https://github.com/Luc45/WooCommerce-Correios-Calculo-de-Frete-na-Pagina-do-Produto/tree/master/.github/workflows

Thank you!

Describe the bug
We've had 10 go at this, and we're getting a fail each time - reviewing the fail message helped us identify a few issues, such as missing package.json and lockfile ( which really are not required for this type of simple plugin, but we added and it helped ) - also complained when we went with version numbers like 1.2.3.4 - 1.2.3 worked ok..

We have a number of outdated plugins and seems a few people would like to see them updated - svn is the main reason they have not been updated on WP...

Steps to Reproduce

You can see the plugin here: https://github.com/qstudio/add-user-metadata
Last action failure here: https://github.com/qstudio/add-user-metadata/runs/1041941502?check_suite_focus=true

Stated reason for failure was not clear - previous failures pointed to something we could fix, but this one simply states:

found 0 vulnerabilities

npm ERR! missing script: build

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2020-08-28T14_37_09_047Z-debug.log
##[error]Process completed with exit code 1.

Expected behavior
Well, that it works!.. We love the idea and Git and we have several other plugins that this could help to bring back to life..

Additional context
The plugin has no build process, it's essentially a single file, which runs in the admin only - nothing complex here, which is why we picked it as a starting point for testing.

Please let me know what other info I can provide.

Thanks for this great release!

Is your enhancement related to a problem? Please describe.
Deploying WordPress plugins to WordPress.org via a monorepo.

Describe the solution you'd like
Instead of deploying the entire branch, it would be nice if a user could alternatively specify a path to the directory which should be synced to WordPress.org. Currently, the action uses the GITHUB_WORKSPACE environment variable for the directory. Maybe this option can be overridden?

Please consider introducing shellcheck in CI https://github.com/marketplace/actions/shellcheck

Describe your question

I'm trying with the yml «Deploy on publishing a new release and attach a ZIP file to the release» but i get this error at Build phase: Can you help me? Thanks!

npm install
npm run build
shell: /bin/bash -e {0}
npm WARN saveError ENOENT: no such file or directory, open '/home/runner/work/manage-admin-columns/manage-admin-columns/package.json'
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN enoent ENOENT: no such file or directory, open '/home/runner/work/manage-admin-columns/manage-admin-columns/package.json'
npm WARN manage-admin-columns No description
npm WARN manage-admin-columns No repository field.
npm WARN manage-admin-columns No README data
npm WARN manage-admin-columns No license field.

up to date in 0.21s
found 0 vulnerabilities

npm ERR! code ENOENT
npm ERR! syscall open
npm ERR! path /home/runner/work/manage-admin-columns/manage-admin-columns/package.json
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, open '/home/runner/work/manage-admin-columns/manage-admin-columns/package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! A complete log of this run can be found in:
npm ERR! /home/runner/.npm/_logs/2021-01-02T22_34_25_185Z-debug.log
Error: Process completed with exit code 254.

Describe the bug
When there are no .gitattributes nor .distignore files present in the build, the action fails.

Please see the action log.

Steps to Reproduce
I'm using a build process that already puts all the clean files into a separate directory and starts the WP.org release from there. So I have only the files which need to be picked up.

Expected behavior
It just passes with all the files.

Describe your question
👋🏻 Is it possible to use this action without an SVN deployment? The .distignore, npm build and .zip attachment to a release is perfect for some non .org plugins of mine, but I don't need the SVN aspect.

Is that possible?

Describe the bug
➤ Preparing files...
svn: E200009: 'trunk/public/assets/images/[email protected]': a peg revision is not allowed here
##[error]Docker run failed with exit code 123

File names with @ sign need to be escaped with double @@

Describe the bug

The action does not pick up the .distignore file and incorrectly commits the .wordpress-org folder.

.distignore
https://github.com/khromov/tickset/blob/4b5cccf/.distignore

Build:
https://github.com/khromov/tickset/runs/436809733?check_suite_focus=true

Log:

Updating 'trunk':
...
Updated to revision 2241995.
➤ Copying files...
ℹ︎ Using .distignore
➤ Preparing files...
➤ Copying tag...
A         tags/1.0.3
A  +    tags/1.0.3
➤ Committing files...
Adding         tags/1.0.3
Committing transaction...
Committed revision 2241996.
✓ Plugin deployed!
...

Resulting files:
https://plugins.svn.wordpress.org/tickset/tags/1.0.3/.wordpress-org/

Steps to Reproduce
See links above.

Expected behavior
.distignore is expected to work.

Additional context
N/A

I'm currently using https://github.com/DevinVinson/WordPress-Plugin-Boilerplate to build my wordpress plugin. I want to use this action to deploy to wordpress.org . However I'm unclear how exactly I can do that since there is no build scripts etc. Just the filter with all plugin files. Any guide to integrate this action with the above mentioned boilerplate would be greatly appreciated.

If there is another boilerplate that works better with this action please offer suggestion as well.

In Git, it is common to prefix tagged versions with v (e.g. v1.2.3), but in the WordPress SVN plugin directory, it's common to have no prefix (e.g. a tag of 1.2.3).

It would be nice if this recognized these patterns and stripped the v prefix when committing the SVN tag.

If the SVN user on the repository owns several plugins, it can be hard to follow with the current message:

Update to version $VERSION from GitHub

It could be nice to be able to set an optional environment var containing the plugin’s name, that would display:

$PLUGIN_NAME: update to version $VERSION from GitHub

Alternatively, the plugin slug could be used, or a fully customable message would also work of course.

Hi,
Im trying to deploy my wordpress plugin to svn using your deploy action but it keeps on constantly failing, I need help locating my problem.

the output my action yields:
Wordpress plugin deploy1s
Set the SVN_USERNAME secret
##[warning]Unexpected input(s) 'SVN_PASSWORD', 'SVN_USERNAME', 'SLUG', valid inputs are ['entryPoint', 'args', 'generate-zip']
Run 10up/action-wordpress-plugin-deploy@stable
/usr/bin/docker run --name cb48c56363b5574ade95f88091aa29529a_629cdb --label 8118cb --workdir /github/workspace --rm -e INPUT_SVN_PASSWORD -e INPUT_SVN_USERNAME -e INPUT_SLUG -e INPUT_GENERATE-ZIP -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/eko-wp-plugin/eko-wp-plugin":"/github/workspace" 8118cb:48c56363b5574ade95f88091aa29529a "false"
allexport off
braceexpand on
emacs off
errexit on
errtrace off
functrace off
hashall on
histexpand off
history off
ignoreeof off
interactive-comments on
keyword off
monitor off
noclobber off
noexec off
noglob off
nolog off
notify off
nounset off
onecmd off
physical off
pipefail off
posix off
privileged off
verbose off
vi off
xtrace off
Set the SVN_USERNAME secret

(for this step, and i fails)
the step in my yml file looks like that:
on:
push:
branches: [ master ]

jobs:
build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v2

- name: Install php dependencies
  uses: php-actions/composer@v2
  with:
    dev: no
- name: Install npm packages and build
  run: |
    npm install
    npm run build

deploy-svn:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2

  - name: create git tag
    uses: Klemensas/action-autotag@stable
    with:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  
  - name: Wordpress plugin deploy
    uses: 10up/action-wordpress-plugin-deploy@stable
    with:
      SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
      SVN_USERNAME: ${{ secrets.SVN_USERNAME }}

any help please?
thanks,
Dean

Is your enhancement related to a problem? Please describe.
When the repository name doesn't match the plugin's slug you can set the SLUG env variable. This one is also used for plugin ZIP if generate-zip is set. This means you can't use the asset_path and asset_name values as shown in the readme example.

Describe the solution you'd like
I'd like to have the action returning the path and ZIP file as output parameters which can be consumed by follow-up actions like actions/upload-release-asset.

Describe alternatives you've considered
Replacing ${{ github.event.repository.name }} with the hardcoded value for the slug.

Where do I add my SVN credentials? Is there a physical secrets file anywhere in my repo?

Describe the bug
Action just throws:

➤ Committing files...
svn: E175013: Commit failed (details follow):
svn: E175013: Access to '/!svn/me' forbidden

Additional context
See the action log.

Is your enhancement related to a problem? Please describe.

I have pushed many tags to SVN, but the recommendation is to delete old tags.

People may want to limit the number of tags in the SVN repository to say the last 5 releases, as making releases older than this available to download may cause side effects.

Describe the solution you'd like

Removing specified tags or restricting the number of tags in the SVN repository could be a feature of this action?

Is your enhancement related to a problem? Please describe.
To improve the docs, it would be nice which scopes the token is required to have

Describe the solution you'd like
A list of scopes required for the personal access token.

Context
Available options:

Describe the bug

svn: E155010: The node '/github/svn-enable-svg-uploads/assets/*.png' was not found.
'assets/*.png' is not under version control
'assets/*.jpg' is not under version control
svn: E155010: The node '/github/svn-enable-svg-uploads/assets/*.jpg' was not found.

Steps to Reproduce

1. Use this action with a github repo without images
2. Observe the error message in action logs

Expected behavior

Only apply checks if such files exist

Additional context

I do not know if this is why SVN failed, or if I have done something else silly, but noticing it was enough to distract me.

Is your enhancement related to a problem? Please describe.
Replacing all of the strings for a version can be problematic. A user needs to find all of the strings and ensure that they are updated correctly.

Describe the solution you'd like
As a precommit action, all of the strings are updated to the proposed tag.

Describe alternatives you've considered
Manual operation, since a bunch of sed commands are prolly overkill here.

I want to test this action on my PC, is there any way to pull this image?

I have tried to pull it from the GitHub registry:
docker pull docker.pkg.github.com/10up/action-wordpress-plugin-deploy:1.5.0
but it looks like I don't have permission
Error response from daemon: repository docker.pkg.github.com/10up/action-wordpress-plugin-deploy not found

Can you send me a link to DockerHub with this image?

Describe the bug
Seems like generated zip file while downloading won't have plugin-slug folder.

Steps to Reproduce

1. Implement github action with generate-zip enabled.
2. After all the process is complete, Open zip file!
3. See error, directly all files from trunk is located!

Expected behavior
ZIP file should have plugin-slug.

Additional context

Hello,

I try your action to test the deployment without SVN and got an error:

Run npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/runner/work/messesinfo/messesinfo/package.json'
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN enoent ENOENT: no such file or directory, open '/home/runner/work/messesinfo/messesinfo/package.json'
npm WARN messesinfo No description
npm WARN messesinfo No repository field.
npm WARN messesinfo No README data
npm WARN messesinfo No license field.

up to date in 0.421s
found 0 vulnerabilities

npm ERR! code ENOENT
npm ERR! syscall open
npm ERR! path /home/runner/work/messesinfo/messesinfo/package.json
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, open '/home/runner/work/messesinfo/messesinfo/package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent 

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2019-11-20T10_01_58_134Z-debug.log
##[error]Process completed with exit code 254.```
Could you please help me ?
Many thanks by advance

Describe the bug
I think it would be much more understandable to name the master branch stable, as its real usage is when being referenced in workflow files (e.g. uses: 10up/action-wordpress-plugin-asset-update@master). There is somewhat of an understanding that in a develop/master pairing that the latter implies stable/latest, but that requires knowing if a project is set up that way, which I think is asking more than necessary from your typical user of this kind of tool.

Additional context
Workflow files can also reference tag names. So our recommendation would be: use stable by default to get the latest release (am open to discussing whether to name this latest instead although IMO that can be read as more along the lines of develop), use develop to test stuff out before we release, and use a tag name like 1.5.0 to ensure nothing changes until you're ready.

PR for this needs to update docs. We do need to leave master in place after creating a replacement but could consider committing a change directly to master that outputs a message recommending you change your workflow file because it will no longer update.

Hello.

Is your enhancement related to a problem? Please describe.
Nope.

Describe the solution you'd like

SVN_URL="http://plugins.svn.wordpress.org/${SLUG}/"

What about moving to https? Unless there is a reason not to?

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?

Describe your question

My plugin uses composer to download tar package from a custom repository. The unpacked tar contains a binary that has executable permission set on the filesystem.

When I run composer install locally all is well.

When i run composer install as an action workflow step right before the 10up/action-wordpress-plugin-deploy step, the executable permission on the binary file does not get reflected in SVN. I believe this is becuase I need to run svn propset on the file to tell SVN that it's an executable.

Any ideas about the best way add this ot the workflow? Is there a hook into the action's SVN process that I'm not seeing maybe something similar to a .distignore file?

Similar to #5, I would like a workflow where I could tag a pre-release, run the build (including zip file), but not deploy to the svn.

The intent is to have a final round of testing with the build artifact before an actual release.

It looks like this would involve rewriting the .distignore workflow to run more like the .gitattributes, and generate the zip file from $TMP_DIR instead of the svn directly.

Does this seems like something useful? I'm not even sure it's doable, to be fair, as I'm just using Github actions now for the first time!

Describe the bug

Deployed with action with "generate-zip" parameter, however, ended with "not found" issue:
used this workflow. Maybe related to SLUG used?

Expected behavior

Attach zip to the release - https://github.com/vyskoczilova/kybernaut-ic-dic/releases/tag/1.6.4

Describe the bug
In my repo, I using this action.

I am seeing builds failing with the following error

Reading package lists...
E: The repository 'http://security.debian.org/debian-security stable/updates Release' does not have a Release file.
The command '/bin/sh -c apt-get update && apt-get install -y subversion rsync git zip && apt-get clean -y && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100

Expected behavior

Additional context

Describe the bug

When running Github Action, it keeps getting my old version of the plugin which returns an error when deploying to WordPress Plugin Directory

Steps to Reproduce

This is the failed actions: https://github.com/dalenguyen/firebase-wordpress-plugin/runs/1801687516?check_suite_focus=true

I tried with a different version of the tag, but it keeps the old one.

When running, it retrieves the old version:

Expected behavior

Github Actions passed

Additional context

Describe the bug
Screenshots can be .gif files. These are useful for showing the interaction the user can expect. The mime-type of .gif files is not updated. So the file will be downloaded, instead of shown in the browser.

Steps to Reproduce

1. Create a repo with an assets folder that contains a .gif file
2. Run the action
3. Click the screenshot in the WordPress plugin page

Expected behavior
The file will open in the browser.

Additional context
PR added.

Thank you for writing this cool GitHub action. I've been putting off seeing how it works until now, but I feel I now have a fairly good idea of it, along with some ways to use this to do something that was manual for me until this point 🏆 to you all.

Describe the bug

When generating or adding files to the filesystem in a github action, the files will not be deployed via SVN unless they are comitted to the repo.

Steps to Reproduce

1. Before running this action, touch or cat to create a file
2. Run this action
3. Notice that the new file is missing

Expected behavior

Files added during release action are transferred automatically for principal of least surprise.

Additional context

I have a plugin with a non-trivial build step. It uses composer to get dependencies and then copies them into a folder.

At first I was blaming the php-actions/composer, but I added a step to check ls -lhaR and it showed my files. It was only after combing every line I realised what this was doing 😆. I Think it's kind of genius to use git archive in this way, but it does lead to user surprise so should likely be documented.

@helen Thank you so much for your excellent work here! This is exactly what I've been looking for. Unfortunately, I'm unable to get the strict working on my end and I'm sure I'm done something terribly stupid. 😂

Here's what I did:

1. Headed over to https://github.com/marketplace/actions/wordpress-plugin-deploy
2. Copied the example workflow file
3. Headed over to my plugin repo and created the secrets and added the example workflow to the actions
4. Bumped up the version number of my plugin and pushed the changes to the repo

Nothing happened though. 🧐

While I do not expect that you offer any support for my individual issue, it would be great having some general "Getting started" steps.

Describe the bug
The docs on generating and attaching a zip appear to not be the latest.

https://github.com/10up/action-wordpress-plugin-deploy#deploy-on-publishing-a-new-release-and-attach-a-zip-file-to-the-release

I've changed mine from

upload_url: ${{ github.event.release.upload_url }}
asset_path: ${{ steps.deploy.outputs.zip-path }}
asset_name: ${{ github.event.repository.name }}.zip
asset_content_type: application/zip

upload_url: ${{ github.event.release.upload_url }}
asset_path: ${{github.workspace}}/${{ github.event.repository.name }}.zip
asset_name: ${{ github.event.repository.name }}.zip
asset_content_type: application/zip

Which I gleaned from https://github.com/WordPress/theme-check/blob/master/.github/workflows/deploy.yml

But won't be able to confirm the change works until the next release cycle (wanted to report now though!)

Also, the repo has a message that it's no longer maintained and to use https://github.com/softprops/action-gh-release instead. Has anyone tried swapping them out?

Describe the bug
No zip file created with generate-zip: true setting.

Steps to Reproduce

1. Configure an action with a subsequent action that awaits for the generated artifacts
2. Let Github run the action
3. Asset action fial with ##[error]Not Found

Expected behavior
The asset action can grab access to the generated zip file.

Additional context
I only tested with a simple plugin without build script Mentioning here because there is a vague description of zip file creation without build script in the README, but I did not properly understand the relationship between build step and the zip file creation.

I also tried with two different asset action: actions/upload-release-asset@v1 and svenstaro/upload-release-action@v2.

You can find my config here: https://github.com/OM4/weatherzone/blob/master/.github/workflows/deploy.yml
And the failed action here: https://github.com/OM4/weatherzone/runs/1066339241?check_suite_focus=true

Describe the bug
The Github workflow run produces three new files that end up in the SVN. Not sure if they are new or have been there for some time and this is known but I get these unrelated files in the SVN:

• DOCKER_ENV
• docker_tag
• output.log

Not sure if it matters but I use a composer based deployment step that runs composer install that could cause this?

Steps to Reproduce

1. Create a tag so the deployment workflow
2. Check the deployed files on WordPress SVN repo

Expected behavior
Not sure but those files seems to contain debugging information not relevant to the published plugin.

Is it save to add those three files to .distignore?

Describe the bug
Pretty much as described. While perhaps not a best practice, there are plugins out there without screenshots or branding imagery.

Steps to Reproduce

1. Tag a release on a repo without a .wordpress-org directory.
2. Check Action run.
3. See error

rsync: change_dir "/github/workspace/.wordpress-org" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
##[error]Docker run failed with exit code 23

Expected behavior
It should check for the directory and skip if doesn’t exist.

Additional context
This is a companion issue to describe the problem #6 is solving. A parallel one will need to be opened for the asset updater action.

Is your enhancement related to a problem? Please describe.
Not related to a problem -- more of an additional documentation.

Describe the solution you'd like
A boilerplate wordpress plugin project that anyone can just clone and easily test using this github action .

Designs
Foo Wordpress Plugin - a boilerplate wordpress plugin implements this wordpress action.

Describe alternatives you've considered
none

Additional context
It would be cool to see a project that anyone can clone and play with immediately .

Hope you would consider my suggestion . Cheers!