Tag Info

New answers tagged

0

I would suggest using a Gerrit + Jenkins environment to keep your master branch always in a good shape. People push their new code to Gerrit which triggers a Jenkins job to pull that patch, builds, tests, and so on. If other developers like your patch and Jenkins completes its job successfully, then Gerrit will merge that piece of code to your master branch. ...


0

We use Jenkins for our build server and use the gatekeeper model for pushing commits -- where a combination of Jenkins and commit triggers (that ensure peer reviewers have done their job) is the gatekeeper. Commits are pushed indirectly through a curl to Jenkins, where it clones the master repo then pulls in the commit(s) to be merged and performs all ...


0

How many times have you gotten that automated email saying your last commit broke the build? How many times is it wrong? But now you have to go check to see if it really was you, or someone else who did another commit around the same time. Or maybe it was something environmental. If the system doesn't know for sure, then I certainly don't want to automate ...


20

Let's agree on terms first. I personally use the terms Continuous Build and Continuous Integration to distinguish two different scenarios: Continuous Build: a tool that checks periodically if the repository changed since the last build, and build/test if it did. Continuous Integration: a tool that takes Pull Requests and validate them against the latest ...


0

The CI should never alter the commit history of the repo. The correct solution here is for no commits to be added to master branch if they haven't been tested and verified. Do you work on feature branches, have the CI run automatically on those, and if the builds fail, don't merge them into master. You can have an additional build that tests merges if ...


5

Is this a best practice or it may be more problematic than just leaving master broken until the developer fixes it? It is problematic. A person deciding "the master HEAD is broken; I will revert the top change" is completely different than the CI system doing the same. Here are a few disadvantages: Errors in the automated reversal process will screw ...


41

I would be against doing this for the following reasons: Any time you set up an automated tool to change code on your behalf, there is the risk that it will get it wrong, or that a situation will arise where you need it to stop making that change (e.g., the latest version of Google Mock had a bug in it, so it's not your code failing) and you have to waste ...


6

Yes. It is good practice to keep most of the version number in vcs. If we consider semantic versioning semver.org where we have major.minor.patch.build the first three must live in vcs. The last one can be a incrementing number from your build server used to backtrack the specific commit that a binary is made from. To facilitate this in .NET we have made a ...


22

Personally, I choose option 3: keep versioning information in VCS metadata, specifically, tags. Git makes it very easy to do so, because there is a command git describe, which can uniquely describe a commit based on a tag. Here's how it works: If the current commit is tagged, output the name of the tag. Otherwise, walk the history backwards until you find ...



Top 50 recent answers are included