4 ms·

In some teams, you are not allowed to submit any commit that breaks the build, and a lint failure would be considered a broken build.

by beart 2y ago

barbazoo 2y ago
You're right, most places I've worked this applies only to a subset of branches, usually main/master and sometimes other branches considered "stable" such as for the staging env.
codetrotter 2y ago
Do these teams run the pipeline on all the commits when you push multiple commits at the same time to your branch? Say I have an open MR from a branch that I’ve pushed three commits to so far. I pushed these three commits individually and the pipeline ran green each time. A coworker of mine points out some errors to me. I have to touch files that I previously touched in the past three commits again. I am tempted to commit these changes in one commit. But I decide to try git absorb instead. So instead of adding one fourth, green commit to my MR, my use of git absorb rewrites all three of my previous commits. But actually, the changes I was about to put in the fourth commit only work when taken together. Splitting them up and rewriting the previous three commits will result in build failure if you try to build from the new first commit or the new second commit. I don’t notice that because I’m on the new third commit. I force push the three new commits to my branch for my MR. Gitlab runs the pipeline on the last of the commits. Everything looks fine to me. Your team lead approves the MR and pushes the merge button. Three months later he scolds me for a broken bisect.
menaerus 2y ago
We are talking about the commit, or series of commits thereof, during the development of code in feature/bug-fix branch and not about the commit that you push as a post-fix because one of your previous commits broke something. That was not the discussion as far as my understanding goes.

4 ms·

In some teams, you are not allowed to submit any commit that breaks the build, and a lint failure would be considered a broken build.

by beart 2y ago

In some teams, you are not allowed to submit any commit that breaks the build, and a lint failure would be considered a broken build.

barbazoo 2y ago
You're right, most places I've worked this applies only to a subset of branches, usually main/master and sometimes other branches considered "stable" such as for the staging env.
codetrotter 2y ago
Do these teams run the pipeline on all the commits when you push multiple commits at the same time to your branch? Say I have an open MR from a branch that I’ve pushed three commits to so far. I pushed these three commits individually and the pipeline ran green each time. A coworker of mine points out some errors to me. I have to touch files that I previously touched in the past three commits again. I am tempted to commit these changes in one commit. But I decide to try git absorb instead. So instead of adding one fourth, green commit to my MR, my use of git absorb rewrites all three of my previous commits. But actually, the changes I was about to put in the fourth commit only work when taken together. Splitting them up and rewriting the previous three commits will result in build failure if you try to build from the new first commit or the new second commit. I don’t notice that because I’m on the new third commit. I force push the three new commits to my branch for my MR. Gitlab runs the pipeline on the last of the commits. Everything looks fine to me. Your team lead approves the MR and pushes the merge button. Three months later he scolds me for a broken bisect.
menaerus 2y ago
We are talking about the commit, or series of commits thereof, during the development of code in feature/bug-fix branch and not about the commit that you push as a post-fix because one of your previous commits broke something. That was not the discussion as far as my understanding goes.