CODEWITHSUNDEEP
gitbitbucketversioning
T Lytle
T Lytle

Reputation: 199

How to Handle Multiple Git Repositories

I work on two different, independent systems and we store our code on BitBucket (Git). The two different systems are housed in two different repositories on BitBucket. Let us just call them 'system1' and 'system2'. Each repository follows GitFlow with a master/develop/release branching scheme.

We also have a separate repository that houses a shared library that is used by both 'system1' and 'system2'. There is also another repository that contains all networking-related software that is also used by 'system1' and 'system2'.

The 'system1' and 'system2' repository each has a build script. The build scripts have an expectation that each of the repositories are cloned at the same directory level. So, for example, like this:

~/system1
~/system2
~/shared_library
~/networking

The build scripts use git describe to tag each build. It uses the output of git describe in each repository to create a build. So, just as an example, the build information out of system1 would look like this:

SYSTEM1: 10.1.1
SHARED_LIBRARY: 10.1.1
NETWORKING: 10.1.1

All of this software is bundled and installed onto the target machine with the SYSTEM1 tag.

The problem I am having is if there is a change in networking then that is not reflected in the build number for system1. For example, let's say a single commit was made to networking. Running the build script now looks like this:

SYSTEM1: 10.1.1
SHARED_LIBRARY: 10.1.1
NETWORKING: 10.1.1-1

When installed, it still looks like version 10.1.1 even though it is not (because the network has changed).

Essentially, I need to change my scheme so that changes in certain other repositories are reflected in the git describe output in system1.

I am unsure on how to accomplish this.

Upvotes: 1

Views: 263

Answers (1)

Will
Will

Reputation: 7057

As a start, how about a build-time test that checks for version updates and fails if a dependency (networking) version is updated but dependent (system1) version is not? Then you could at least automatically detect and manually resolve outdated dependent versions. In your example where networking is incremented but system1 is not, when building system1 in such a state, the test would fail and thus so would the build. Depending on your needs, implementing the test might be as simple as checking for the existence of any -<commits> (e.g. -1) suffix in any dependency. Or as complex as checking your artifact repository for the latest built artifact version. The precise logic is pretty dependent on your environment.

Then as an optional next step, you could move to automate the incrementing of versions altogether. Instead of manually tagging in BitBucket, have the build system (or even just a manually kicked-off but otherwise automated promotion script) increment versions rather than you manually setting them. This automated solution could do things like automatically cascade version increments from dependency (networking) to dependent (system1). You can potentially use this same sort of system to do the tagging automatically, e.g. on a successful build. I've seen portions of this approach used successfully.

There may also be a solution that leverages git more, but one nice thing about automating some of your version checks or increments in your build system is that it can potentially make your pipeline less dependent on your implementation technology choices (e.g. git, npm, specific languages, etc.).

Upvotes: 1

Related Questions