feat(git/deps): allow controlling git dependencies #19
Conversation
Allows modification of the git dependency which causes rebuilds as it might not be desired in all usecases. By defaults we keep existing behaviour. Signed-off-by: Tiago Castro <[email protected]>
|
@de-vri-es would this be of interest? Thank you |
Added git dependencies: fusion-engineering/rust-git-version#19 This allows us to avoid rebuilds when staging changes. Also added another feature to avoid rebuilds altogether. Eg: if git versions are specified via env variable then we don't need to use git from within the rust-build at all. This is fine for most dev setups if we don't care about versions locally testing. Signed-off-by: Tiago Castro <[email protected]>
Added git dependencies: fusion-engineering/rust-git-version#19 This allows us to avoid rebuilds when staging changes. Also added another feature to avoid rebuilds altogether. Eg: if git versions are specified via env variable then we don't need to use git from within the rust-build at all. This is fine for most dev setups if we don't care about versions locally testing. Signed-off-by: Tiago Castro <[email protected]>
Added git dependencies: fusion-engineering/rust-git-version#19 This allows us to avoid rebuilds when staging changes. Also added another feature to avoid rebuilds altogether. Eg: if git versions are specified via env variable then we don't need to use git from within the rust-build at all. This is fine for most dev setups if we don't care about versions locally testing. Signed-off-by: Tiago Castro <[email protected]>
Added git dependencies: fusion-engineering/rust-git-version#19 This allows us to avoid rebuilds when staging changes. Also added another feature to avoid rebuilds altogether. Eg: if git versions are specified via env variable then we don't need to use git from within the rust-build at all. This is fine for most dev setups if we don't care about versions locally testing. Signed-off-by: Tiago Castro <[email protected]>
Added git dependencies: fusion-engineering/rust-git-version#19 This allows us to avoid rebuilds when staging changes. Also added another feature to avoid rebuilds altogether. Eg: if git versions are specified via env variable then we don't need to use git from within the rust-build at all. This is fine for most dev setups if we don't care about versions locally testing. Signed-off-by: Tiago Castro <[email protected]>
This comment was marked as resolved.
This comment was marked as resolved.
|
Could you elaborate a bit on the use case for this? I can't think of a reason why you wouldn't want a rebuild after the git information changed. |
Let's see, haven't look at this for a while but IIRC because index is added, staging changes causes rebuilds to happen which was the initial thing I was trying to avoid, as staging a file doesn't change the current sha but it does trigger a rebuild as is! More specifically for our use case, for dev builds we're not so picky about the the commit sha anyway, even if it gets slightly wrong we don't care too much as we have separate image build procedure via nix when we want correct commit/tag with correct build dependencies etc. |
I'm not sure why we added the index actually. Staged changes are still dirty changes, so I'd think HEAD should be enough.. But I want to verify this more before making any decisions based on this.
Hmm. The macro should still function correctly, even if some class of problems doesn't matter for some cases where everything gets built in a controlled manner. I'm not convinced there is enough reason to add a knob to tweak this. In particular, letting the user specify what files to depend on is too complicated. If there is something simpler that makes sense we could consider including it. But for now I'm inclined not to add any customization of the git files to depend on. I'm open for discussion on why we add a dependency on the index though. |
Allows modification of the git dependency which causes rebuilds as it might not be desired in all usecases.
By defaults we keep existing behaviour.
Signed-off-by: Tiago Castro [email protected]