Today let’s talk about simple and effective sharing code between repositories which Snake CI brings in the 0.4.0 version.
As a software product grows, the codebase grows too, which inevitably lead to a code duplication of a shared code used in different parts of the project.
A code duplication leads to bugs, makes project structure less organized, which eventually results in a much slower release cycle and overall quality drop.
The common approach to handle shared code duplication is to extract it into a separate repository as a library with its own release cycle.
The extracted library can be linked to the project using either Git
submodules or package managers like
Git submodules allow you to put a Git repository as a subdirectory of another Git repository. It lets you include another repository into your project and keep your development history separate.
Git submodules are language agnostic and do not require any other tools except
To link library code back to the main project using submodules use
submodule add command:
git submodule add git+ssh://email@example.com:7999/libraries/our-lib.git \ deps/our-lib git commit -m "integrate our-lib"
In this example, we use the previously extracted shared library called
and add it back to the main project.
Submodules are the most straightforward approach which works with Snake CI out of the box without any additional configuration.
Submodules code appears in the CI environment right after the clone step.
It is also possible to use your preferred package manager to manage dependencies.
Let’s see how to add extracted libraries using
npm as an example package
First, we need to add
our-lib into the main project by executing
install and providing it with the path to the repository hosting shared
npm install -S 'git+ssh://firstname.lastname@example.org:7999/libraries/our-lib.git'
However, to fetch this dependency later in the CI pipeline, an additional step is required.
By default, SSH requires
to add any remote server to the trusted list manually.
Since we’re going to fetch dependencies from the Bitbucket instance and this
instance is trusted, we can skip remote server verification step by specifying
GIT_SSH_COMMAND environment variable in the
variables: GIT_SSH_COMMAND: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
GIT_SSH_COMMAND environment variable is set,
npm install can be
used as usual to fetch all dependencies.
snake-ci.yaml may look like this:
variables: GIT_SSH_COMMAND: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no stages: # other stages listed here - deps # other jobs defined here fetch npm dependencies: stage: deps image: node commands: - npm install
This is all that is required to configure Snake CI to fetch dependencies from the Bitbucket instance.
Code deduplication for shared libraries works well by itself, but without proper version management it may lead to a new set of problems, such as implicit library updates that cause breaking changes in the product.
To avoid these problems altogether, you need to version and publish shared libraries accordingly.
One of the popular versioning approaches is called semantic versioning, which suggests using the following
MAJORis incremented when you make incompatible changes,
MINORis incremented when you add functionality in a backward-compatible manner, and
PATCH(optional) is incremented when you make backward-compatible bug fixes.
Using this approach, we can tag individual commits with specific versions
git tag command:
git tag v1.2.3 # will tag current master with v1.2.3 tag git push --tags # will push tags to the remote server (note --tags)
Snake CI can be configured to automatically publish a tagged version to
a private package repository (like Sinopia) with the use of the
that now supports the regular expressions syntax.
For example, you can use the regular expression syntax in the condition to
include into a pipeline the job which publishes stable release only when
the tag like
v1.2.3 is specified.
We need to define a job that publishes stable release. In this example,
npm publish in the
publish stable release job definition.
stages: # other stages listed here - deploy # other jobs defined here publish stable release: stage: deploy only: tags: - /^v\d+/ commands: - npm publish # publishes package to the private or public registry
tags parameter means that job will be executed only if the listed tags are changed.
/^v\d+/ expression in the
only: tags section.
/ character means that the tag name will be
matched against the given regular expression. If you're not familiar with
^v\d+ means, that
an incoming tag name must be started with the letter
v that is
followed by at least one number (e.g.,
^requires match from the beginning of the tag name,
vis just plain letter,
\dmeans any number in range 0–9,
+means that previous subpattern (in our case it's 0–9) may be repeated any number of times, but at least once.
If the tag name doesn’t conform to the specified pattern, then the regular
expression doesn’t match, and the
publish stable release job is skipped.
Therefore, to trigger the described job, we need to create a tag in the Git
git tag command, like this:
git tag v1.2.3; and then push
it to Bitbucket using
git push --tags.
To accommodate with needs of growing software projects and to open possibilities
for tackling an increasing complexity, we’ve introduced the new version
of Snake CI — 0.4.0, that includes:
onlysection of a job definition,
If you need assistance or want to say hi, contact us: