Skip to content

Introduce `gems/gitlab-utils` gem

Kamil Trzciński requested to merge gem-gitlab-utils into master

What does this MR do and why?

This tries to improve situation of lib/ folder by moving things that are generic, and can be re-used into its own gems.

This is first take to move some aspects of common rspec practices and common utils.

There's a some amount of changes required to rename some code that is more interleaved with rest of GitLab. In general it appears that almost everything out of lib/gitlab/utils/ could be moved into gems/gitlab-utils/.

It also showcases that every place where we use fast_spec_helper should in fact be its own Gem, for example running rspec on gitlab-utils just takes a fraction of second, since very minimal amount of code needs to be loaded.

How it relates to vendor/ and why not vendor/?

I think conceptually we should consider the vendor/ to be external dependencies, that are pulled from outside.

The usage of gems/ makes it explicit that this is rather "our" maintained code. It also means that we should consider moving most of code that is currently / into gems:

  • sidekiq_cluster
  • metrics_server
  • etc.

The idea behind gems/ is that if code gets more matured, we could consider pulling this into separate repository and publish this to RubyGems.

Why not a separate project?

Gems that are in separate projects and published into RubyGems are very good to have as it allows outside of GitLab use it. However, I think this creates initially too much friction "for us".

Having gems in mono-repo allows people to extend them much easier or add new ones instead of having to establish the whole new repo, with LICENSE, READMEs, CoC, and maintainers or who can publish.

Once the gem is "mature" we can then consider moving this outside into separate repo to reduce a size of mono-repo. However, I'm yet to see when this actually "might" happen.

Adding new gem into repo is more like bundle exec gem my-new-gem and reference it via path:.

References

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Kamil Trzciński

Merge request reports