Bug fix: don't error out on out-of-sync lock file

[jrfnl]

Description

As far as I can see, the --no-check-lock argument has been available since Composer 1.0, so adding this argument to the composer validate command should be safe and should prevent the issues as reported in #206.

Includes tests (though the test isn't running properly yet).

Motivation and context

Fixes #206

How has this been tested?

I've tested this locally with the plain command with both Composer 1 and 2, but have not tested this in the context of this action.

I've added a unit test, but haven't managed to get it running properly.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

PR checklist

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• I have added tests to cover my changes.

[ramsey]

Aside from the typo causing problems in the test, this looks great to me. I think this is the right approach. Thanks!

[ramsey]

I wonder if that's because it needs the executable bit. Do you have a way of setting chmod +x on that file and committing that change?

[jrfnl]

I wonder if that's because it needs the executable bit. Do you have a way of setting chmod +x on that file and committing that change?

Ha! Yes. That was it! Might be useful to add that information to the CONTRIBUTINGfile.

If it helps, even though file permissions are not handle the same on Windows, the git ls-files -s command to check the status works and will show the correct chmod status. The permissions for a file can be changed on Windows by running this command: git update-index --chmod=+x <file>.

I've updated the PR and have verified the new test fails without the fix and passes with the fix in place, so should be good to go now.

Thanks @ramsey for coaching me through this one.

[codecov]

Codecov Report

Merging #213 (bf53470) into v2 (6e86502) will decrease coverage by 0.70%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##               v2     #213      +/-   ##
==========================================
- Coverage   88.70%   88.00%   -0.71%     
==========================================
  Files           5        5              
  Lines         124      125       +1     
==========================================
  Hits          110      110              
- Misses         14       15       +1     

Impacted Files	Coverage Δ
bin/composer_paths.sh	87.80% <0.00%> (-2.20%)	⬇️

[jrfnl]

Hmm.. curious that Codecov doesn't pick up on the new unit test...

[ramsey]

Hmm.. curious that Codecov doesn't pick up on the new unit test...

I'm still learning how the Bash code coverage tooling works. 🤷🏻‍♂️

[ramsey]

I have a suspicion that multi-line commands in Bash (like this one) aren't being correctly reported.

[jrfnl]

That might well explain it, though the second line of the command is recognized as covered (correctly).

[Edit]: on second look, no doesn't seem to be recognized either, so yeah, you're right. Multi-line commands seem to be the issue.