You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you update a harness package without changing the harness.exs, i.e. mix harness.update, a subsequent mix harness.check run will pass. Probably shouldn't since a change to the templates in the package would likely change the .harness output.
Currently harness.check uses a hash of the harness.exs to do its check. Seems like it would be reasonable to include the harness.lock file in that hash or do separate hashes and check both.
I came around looking for a quick way to include harness.lock in the hash. The current implementation of the hash and check seems very coupled to the manifest file only, so leaning towards adding a harness.lock hash check to the task.
Alternatively, we could just wipe out the .harness/.manifest.hash file when doing a harness.get or harness.update task.
The text was updated successfully, but these errors were encountered:
If you update a harness package without changing the
harness.exs
, i.e.mix harness.update
, a subsequentmix harness.check
run will pass. Probably shouldn't since a change to the templates in the package would likely change the.harness
output.Currently
harness.check
uses a hash of theharness.exs
to do its check. Seems like it would be reasonable to include theharness.lock
file in that hash or do separate hashes and check both.I came around looking for a quick way to include
harness.lock
in the hash. The current implementation of the hash and check seems very coupled to the manifest file only, so leaning towards adding aharness.lock
hash check to the task.Alternatively, we could just wipe out the
.harness/.manifest.hash
file when doing aharness.get
orharness.update
task.The text was updated successfully, but these errors were encountered: