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
The point of this idea is to define git/source-control change based dependencies on tasks such that a task which depends on them will no-op if nothing has changed. At it's most basic, if i say task "foo" depends on src/.*, and git diff --name-only | grep 'src/.*' doesn't yield anything then "foo" should be considered done without executing.
Imagine a folder structure
justfile
subproject1/
subproject2/
subproject1and2/ # depends on 1 and 2
Dockerfile
and justfile (syntax just off the top of my head)
build-subproject1: git:src/* git:Cargo.toml
cd subproject1 # I haven't yet checked whether `cd` works like this in just.
cargo build
build-subproject2: build-subproject1 git:src/* git:Cargo.toml
cd subproject2
cargo build
build-docker: Dockerfile git:subproject1/src/*
...
build: build-subproject1 build-subproject2 build-docker
The basic idea is that (even locally, but especially in CI), if I make/just build, you really only want to have to build any individual subproject if src/* for that project has changed. With build-subproject1: git:src/* git:Cargo.toml you're saying "its only possible for the result of build-subproject1 to change and need to be re-run if src/* changed or if Cargo.toml changed.
Perhaps rust subprojects aren't the best examples, I personally conceived of the idea in a mono-ish repo set of python sub-projects which have much more obvious dependence on on-disk file changes.
The Dockerfile example is another typical one. If you specify all the things you depend upon in the Dockerfile, then you could reliably avoid multi-minute docker build/push jobs in CI where you may not have proper image caches ready.
Or even in this (just) project, you update the README, presumably your CI will then waste a bunch of credits spending time building, testing, etc on jobs that cannot possibly produce different results (at least as far as your PR changeset is concerned).
Long story short, I recently got far enough through prototyping my own make-esque-rust-tool to prove to myself that the idea would work; before i realized how much effort it would actually take for me to realistically replace my current-day uses of make.
Then just just popped up on my reddit feed and i figured I'd at least write the idea down somewhere it might possibly get turned into a feature and save me a bunch of effort :P
The text was updated successfully, but these errors were encountered:
It's not entirely obvious to me how that feature would solve this issue, in and of itself. Although it does seem like the way this would get implemented. One would have to manually insert @# {{ git diff --name-only | grep 'src/.*' }} (per my example) into each task?
The point of this idea is to define git/source-control change based dependencies on tasks such that a task which depends on them will no-op if nothing has changed. At it's most basic, if i say task "foo" depends on
src/.*
, andgit diff --name-only | grep 'src/.*'
doesn't yield anything then "foo" should be considered done without executing.Imagine a folder structure
and
justfile
(syntax just off the top of my head)The basic idea is that (even locally, but especially in CI), if I
make/just build
, you really only want to have to build any individual subproject ifsrc/*
for that project has changed. Withbuild-subproject1: git:src/* git:Cargo.toml
you're saying "its only possible for the result ofbuild-subproject1
to change and need to be re-run ifsrc/*
changed or ifCargo.toml
changed.Perhaps rust subprojects aren't the best examples, I personally conceived of the idea in a mono-ish repo set of python sub-projects which have much more obvious dependence on on-disk file changes.
The
Dockerfile
example is another typical one. If you specify all the things you depend upon in the Dockerfile, then you could reliably avoid multi-minute docker build/push jobs in CI where you may not have proper image caches ready.Or even in this (
just
) project, you update the README, presumably your CI will then waste a bunch of credits spending time building, testing, etc on jobs that cannot possibly produce different results (at least as far as your PR changeset is concerned).Long story short, I recently got far enough through prototyping my own make-esque-rust-tool to prove to myself that the idea would work; before i realized how much effort it would actually take for me to realistically replace my current-day uses of
make
.Then
just
just popped up on my reddit feed and i figured I'd at least write the idea down somewhere it might possibly get turned into a feature and save me a bunch of effort :PThe text was updated successfully, but these errors were encountered: