At work we are managing multiple repositories. Also repositories where the context is exactly the same. For example: We are developing an application providing multiple endpoint to our clients. We also developing an api-sdk for our clients to communicate with our apis.
Right now, this is all done in two separate repositories.
Which is absolutely fine. But I kind of don't like it anymore.
The problem with separate repositories for a single context
What happens if you change an API and you have to adjust the contract for it?
- clone API-SDK repository
- clone API
- make changes to your API
- make changes to your API-SDK
- require dev-branch (or local link) from API-SDK into API
- write tests for your API with the changed contract
- tag API-SDK with new version
- release API changes
As you can see, these are a lot of steps you have to do while working with the API.
So, what can we do about it?
Monorepo to the rescue
If you don't know what a monorepo is, or why you should care about. Check out the blog post from @tomasvotruba All You Always Wanted to Know About Monorepo But Were Afraid To Ask
Adding the SDK into the repository of the API makes thing easier than ever. You can now work directly on the SDK in the latest version, write your tests immediately from inside your API.
If everything works, just tag it and publish your package.
Easy right? Right?
How to publish packages from your monorepo
When it comes to the part of actually publishing packages from inside your monorepo you have to get creative with a lot of git commands, or other existing tools like symplify/monorepo-builder from @tomasvotruba
In the latest version, he added the support for github and gitlab, so you can just include this as a workflow action and you are done for. This is awesome!
There is a but! Using the github action in my company was not a real option since we are using an on-site bitbucket server. Damn it!
Gone are the dreams of easy monorepo splitting :(
Docker to the rescue
If you don't know, Github actions is working with docker in the background. So, actually I could just use the docker image and run it myself, right?
Yes I Can!
But what about the direct reference to Github and Gitlab for the splitter?
Well, lucky for us, we can just set some environment variables from bitbucket and everything works as expected :)
The only "hack" we need to do, is to set the GITLAB_CI=bitbucket environment so that we don't need to deal with the prefix INPUT_ from Github.
Running the docker image
So how can I run the splitter using docker?
Well, here is a little bash script to do it.
docker run \
-e GITLAB_CI=bitbucket \
-e PAT="user:accesstoken" \
-e PACKAGE_DIRECTORY=packages/test-package \
-e REPOSITORY_ORGANIZATION=org \
-e REPOSITORY_NAME=test-package \
-e BRANCH=master \
-e REPOSITORY_HOST=bitbucket.host.de/scm \
-e CI_COMMIT_SHA=$COMMIT_SHA \
-e USER_NAME="User Name" \
-e USER_EMAIL=user.name@email.de \
-e TAG=$TAG \
--workdir=/bitbucket/workspace \
-v $(pwd):"/bitbucket/workspace" \
--rm \
symplify2/monorepo-split:latest
Gitlab allows the login using only accesstoken. But we can just pass the username:accesstoken as PAT for the splitter.
Also the REPOSITORY_HOST is not only the host, but contains also a part of the basepath to the repositories.
One important change is the --workdir and -v option. The workdir has to be set, as we need our sources inside the running container and the can't override the sources from the splitter itself. So we need another folder where we link our current working directory into it.
And thats it. It works perfectly :)
Thanks @tomasvotruba for this amazing tool <3
Top comments (0)