You must log in or register to comment.
The worst is when some mfr pushes code that doesn’t compile so when you get latest the whole build is broken
CI and basic PR rules should gate this entirely… this should never be a problem.
basic PR rules
My company’s code leads :
No needs for pull requests when you commit directly to main.
also remember to use --force when pushing, your colleagues will love you
git rebase -i --root git commit --amend --no-edit git push --forceuse the force Luke!
Working in a startup is truly an experience
You owe 2 tokens to the “should jar”.
I don’t get it. How can we tell this is in prod?
You can’t tell that from the screenshot, but I can tell you that I took this screenshot on my Linux box, while upgrading my system packages as an end-user.
I believe, the problem comes from a community repo I added, which doesn’t have to adhere to quite the same quality standards, but evidently they have some distinction between build envs and production envs, and well, I’m at least hoping that my laptop isn’t deemed a build env… 🙃
Ah! So build implies non-production?
My usage of the word “production” was a bit non-standard here, in case that confuses you.
Normally, it’s used for hosted services, where you have the three hosted environments “development”, “integration” and “production”.
In this case, I’m guessing, it’s rather the case that they had a build configuration for running it in their “build-env”, so probably a CI/CD runner. And then there would be a different build configuration for when they’re creating a release distribution.
In a very abstracted sense, the “production” environment is where you roll out your release distribution to, so if you will, my laptop is one of thousands of production environments for this application, but only tongue-in-cheek…
