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.
If you update a harness package without changing the
harness.exs, i.e.mix harness.update, a subsequentmix harness.checkrun will pass. Probably shouldn't since a change to the templates in the package would likely change the.harnessoutput.Currently
harness.checkuses a hash of theharness.exsto do its check. Seems like it would be reasonable to include theharness.lockfile in that hash or do separate hashes and check both.I came around looking for a quick way to include
harness.lockin the hash. The current implementation of the hash and check seems very coupled to the manifest file only, so leaning towards adding aharness.lockhash check to the task.Alternatively, we could just wipe out the
.harness/.manifest.hashfile when doing aharness.getorharness.updatetask.