-
-
Notifications
You must be signed in to change notification settings - Fork 618
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
Add checksum for "generates" (proof of concept) #1816
base: main
Are you sure you want to change the base?
Conversation
Hi, I have a similar issue with the "generates" combined with the "sources": when I remove or edit one output file, the task is not rebuilt and considered "up to date". I can confirm this PR fixes the issue. Example task file (with an existing file # yaml-language-server: $schema=https://taskfile.dev/schema.json
version: '3'
tasks:
build:
sources:
- input.txt
generates:
- output*.txt
cmds:
- echo "test" > output1.txt
- echo "test" > output2.txt Result without this PR ( $ task build
task: [build] echo "test" > output1.txt
task: [build] echo "test" > output2.txt
$ rm output1.txt
$ task build
task: Task "build" is up to date Result with this PR: $ task build
task: [build] echo "test" > output1.txt
task: [build] echo "test" > output2.txt
$ rm output1.txt
$ task build
task: [build] echo "test" > output1.txt
task: [build] echo "test" > output2.txt
$ task build
task: Task "build" is up to date |
@andreynering / @pd93 / @vmaerten : any feedback on this approach ? For my particular project this fixes a real issue and I'd like to have it fixed upstream if possible rather than maintaining my own fork for that |
Also add workaround for building with go 1.23 (see vektra/mockery#803)
Follows the same algorithms than for sources, should be much more understandable & reliable
9d74dc2
to
580492b
Compare
Still working fine for me after the latest changes. 👍🏻 |
Avoid writing any state in IsUpToDate, instead return the current source state and also check after the task is run that the sources checksum has not been modified
- use the full relative path and not only the base name for hashing - if we encounter a symlink, hash the link and not the target path - properly close file on error
580492b
to
1d638a7
Compare
I'm looking forward to this feature. |
Hi,
Here"s a quick proof of concept implementation for properly solving #1741
I believe this approach makes sense and I'm willing to work on this (add relevant unit tests, maybe refactor to avoid using a file to keep the original sources hash...) if you think this is worth it !
Best regards,
Vincent