Revert changes in vendor directory to fix SVN error #55
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the Change
Multiple times when using this Action we've run into issues where trying to push out changes to the
readme.txt
file doesn't work due toOther files have been modified; changes not deployed
.If you have a plugin that uses composer to install non-dev dependencies (or use it for the autoloader), when running this Action, you'll typically run
composer install --no-dev
as part of a build step.Composer
will use a hash for some of the function names and this hash may change each time things are built.When this Action compares the files from the SVN repo to what is in Github, those composer generated files don't match up due to these different hash values, resulting in the above error.
I figured out we can fix this issue by ignoring changes in
vendor/composer
andvendor/autoload.php
.Closes #49
How to test the Change
I am not sure if there's a best practice for how to test things here without accidentally deploying things to the .org SVN repo but here are the steps I took that others can follow:
develop
branch.deploy.sh
file, comment out lines 11-14 and 16-19. These lines deal with setting the svn username and password, which we don't want to do to avoid accidentally committing changes.deploy.sh
.deploy.sh
file, comment out lines 114-116. These lines deal with syncing assets in the svn directory.deploy.sh
file, comment out lines 188-199. These lines are what actually commit the changes. They shouldn't work without a proper username and password but I feel better removing thosead-refresh-control
) that uses composer and runs whatever production build steps this plugin needs. The goal is to end up with a plugin built the same way you would before deploying it to .org./deploy.sh
. You should get an error about other files being modified and right above that line, you should see somevendor
directories being flaggedfeat/auto-ignore-vendor-directory
branch../deploy.sh
again. You should get a message sayingNothing to deploy!
or other but right above that you should see lines about reverting thevendor
directoryThis is the deploy.sh script that I used for testing.
Changelog Entry
Credits
Props @dkotter, @cadic @ravinderk
Checklist: