Difference between revisions of "Continuous Integration: FAQ"

Revision as of 20:41, 6 July 2019

Q: What do I keep in a Git Repository?

A: For a correct answer, we first need to point out a fundamental difference between SVN and Git:

• In SVN, there is one single repository, whose structure is equivalent to a file system. You can check out and work at any level of the SVN tree.
• In Git, there are several repositories, independent from each other. You need to clone an entire repository to work on its content.

Given that, a Git repository holding modules not connected among them (i.e. a repository with modules not grouped in a reactor build of a parent POME) is strongly discouraged. Such repository would force a developer to clone the entire repo, regardless the module he/she would work on. Also Jenkins would be in the same situation: clone a full repo to then build just a small piece of it.

Therefore, there are two ways to structure the content of a Git repository:

1. as single software component
2. as Maven multi-module project

A good way to start with is to create a Git repo for each Eclipse project. So, if you have a multi-module project with Maven in Eclipse, a single Git repo works fine. The same is for an Eclipse project with a single Maven component. The basic idea is that the POM in the root folder of the Git repo should build and deploy all the artifacts held in the Git repository. Jenkins also benefits from this type of structure because it just needs to invoke the root POM.

Aggregating modules logically connected into a single Maven multi-module project is recommended, whenever possible. It helps reduce the number of Git repositories and Jenkins projects, towards a better sustainability of the integration and delivery procedures.

Q: Can I aggregate SVN projects into a Git Repository with git-svn?

A: No, it's not possible. git-svn works like svn: it can convert an SVN folder (and its sub-folders) into a Git Repository. Two folders at the same level of the SVN tree cannot be imported into the same Git repository.

Q: What merge strategy should I use for my Git Repository?

A: With the task branching strategy we adopt in gCube, the fast-forward merge is the preferred way. Since the master branch does not diverge from the branches with task branching, then it can be fast-forwarded: simply updated to point to the same commit as the latest origin/master. Usually, no special steps are needed to do fast-forwarding; it is done by git merge in the situation when there are no local commits.

Q: Can I use rebase to update master from a task branch?

A: No. Rebasing re-writes the project history by creating brand new commits in master for each commit in the original branch. The golden rule of git rebase is to never use it on public branches. The rebase moves all of the commits in the task branch onto the tip of master. The problem is that this only happened in your local repository. Jenkins or others that pulled master are still working with the original master. Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s.

Q: Can I ‘mvn deploy’ from my development machine?

A: Yes, you can. Snapshot builds on jenkins do not use the gucbe-snapshot repository to resolve dependencies, only a local repository. This way, jenkins builds do not depend on the deployments performed by single developers (and potentially not in sync with the Git repository)

Q: Do we still have the subsystems (in Git/Jenkins/Maven)?

A:

• In Git we have a flat list of Git repositories inside the gCubeSystem organization.
• In Jenkins we also have a flat list of projects. Something to be decided is how to create the list of components (Jenkins projects) belonging to a release. This is a duty of the Release Manager.
• In Maven there are not changes.

Back to the CI guide.