-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Git to manage XDMoD test artifacts #143
Conversation
55227f2
to
02cae49
Compare
@@ -14,5 +14,12 @@ if [ ! -x "$phpunit" ]; then | |||
exit 127 | |||
fi | |||
|
|||
artifacts_dir="./xdmod-test-artifacts" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this out to a separate setup script and then call it here. Also move the test artifacts directory somewhere else since it could (and will) be used by the integration_tests and regression_tests.
I've pushed a new commit that moves the artifact repo setup code from
* = prepend My suggestion would be to (as part of a separate pull request) modify Open XDMoD's layout to match SUPReMM's layout. If that will be done, then I'll rebase the code to resolve conflicts if the changes I've made so far look good. |
6b38368
to
3c8a8d8
Compare
3c8a8d8
to
fb82376
Compare
Description
This pull request moves responsibility for retrieval of
xdmod-test-artifacts
from Composer to the scripts that use it.Motivation and Context
Copying/paraphrasing from an email exchange between @smgallo, @jpwhite4, and I:
Composer's design is built around pulling in runtime and development software packages in a consistent, well-considered manner, and the lock file's use of hashes for both individual dependencies and the contents of the lock file is meant to help guard against changes that haven't been tested. For example, if two pull requests both change the lock file and one gets merged, the other will be in conflict with the target branch due to the lock file's content hash being changed by both pull requests. As part of resolving the conflict, the outstanding pull request's lock file will need to be regenerated to include the changes from the other, which in so doing will (partially) validate the combined changes.
Having developers run commands that modify the lock file as part of the testing procedure leads to more work and more opportunities for accidentally pushing bad changes to the lock file. What this pull request does instead is have the scripts that use the test artifacts repo pull in the latest version of the repo with plain Git at run time. This means no updates to run manually and no files in the code repos to tweak and accidentally break when adding to the artifacts.
Tests Performed
Ran a test run of Travis on my fork and ran the unit tests manually on my local system.
Checklist:
I have added tests to cover my changes.