4 ms·

One way in which it is useful, is that you can tag your build artifacts (like docker images) with the commit id in the development branch, and just re-tag them

One way in which it is useful, is that you can tag your build artifacts (like docker images) with the commit id in the development branch, and just re-tag them when you want to promote the artifact to main or production, or whatever. Without this option, you have to either rely on branch names when promoting, which means you can't tie your build to a specific commit in your main branch anymore[1], or you can rebuild your image from the new commit, potentially producing an entirely different artifact which might differ from the one you just tested and validated on your development branch. [1] Unless you back-fill that information after merge, but the workflow is getting really convoluted at this point.

seba_dos1 4y ago
If your branch is not fast-forwardable and has to be rebased before merging, then you wouldn't be able to reuse the artifact from development branch anyway as your production branch is already somewhere else than your development branch was. If it is fast-forwardable, then individual commit IDs don't change at all and you only get a single, effectively empty, merge commit on top of them, so you actually can reuse the artifact just fine.
masklinn 4y ago
> One way in which it is useful, is that you can tag your build artifacts (like docker images) with the commit id in the development branch, and just re-tag them when you want to promote the artifact to main or production, or whatever. I don't understand what you're talking about. The development build artifacts are useless afterwards, you can't "promote" an artifact from development to main without rebuilding unless you're basically the only person working on it, as the integrated behaviour (and thus the corresponding artifacts) can differ from the pre-integration ones. The only situation where you could reuse the development artifacts as-is with no risk is if the branch is fast-forwardable. Which the integration could just take in account by not rebasing branches which are already rebased. > potentially producing an entirely different artifact which might differ from the one you just tested and validated on your development branch. You need one anyway, even if the development branch validates it still has to be validated post-integration as it may fail at that point. > [1] Unless you back-fill that information after merge, but the workflow is getting really convoluted at this point. Is it? All of it is easily automatable. Why are you limiting yourself for things the computer takes care of?

seba_dos1 4y ago

If your branch is not fast-forwardable and has to be rebased before merging, then you wouldn't be able to reuse the artifact from development branch anyway as your production branch is already somewhere else than your development branch was. If it is fast-forwardable, then individual commit IDs don't change at all and you only get a single, effectively empty, merge commit on top of them, so you actually can reuse the artifact just fine.

masklinn 4y ago

> One way in which it is useful, is that you can tag your build artifacts (like docker images) with the commit id in the development branch, and just re-tag them when you want to promote the artifact to main or production, or whatever. I don't understand what you're talking about. The development build artifacts are useless afterwards, you can't "promote" an artifact from development to main without rebuilding unless you're basically the only person working on it, as the integrated behaviour (and thus the corresponding artifacts) can differ from the pre-integration ones. The only situation where you could reuse the development artifacts as-is with no risk is if the branch is fast-forwardable. Which the integration could just take in account by not rebasing branches which are already rebased. > potentially producing an entirely different artifact which might differ from the one you just tested and validated on your development branch. You need one anyway, even if the development branch validates it still has to be validated post-integration as it may fail at that point. > [1] Unless you back-fill that information after merge, but the workflow is getting really convoluted at this point. Is it? All of it is easily automatable. Why are you limiting yourself for things the computer takes care of?