Distributing and re-using your private maven artefact using github registry

The Why?

While working on a maven project or any other build tools like gradle, we come across a lot of dependencies while building a project.
The idea is to not write boilerplate plate and re-invent the wheel by utilizing existing dependencies in a project.
While working in an organization, we come across some libraries privately owned by the organization or something that we developed and want only specific teams or groups of people to use.

In order to share these build artefacts, such as for maven/gradle build tools, we can either share it using privately owned collaboration tools. But then the idea of updates, patches and improvements that needs to be done across teams for same artefacts become cumbersome and hard to maintain.

A simple idea is to upload the artefacts in a secure place where dependent services can download these using some credentials.

Here I will discuss 2 approaches to do this:

1. Github Registry Github provides a artefact registry where among other things you can build and deploy your artefact so it can be used by everyone as a public artefact or even privately owned. Here are the steps to do so:

a. create your library that you want to deploy

b. add distributionManagement attributes to your project object mode file, pom.xml specifiying which repository you want your code to be put into.

c. do mvn deploy to deploy your artifact as a dependency.

d. you should see your artifact deployed in corresponding package.

e. restrict the use of artefact by making your repo private, or you can keep it public. For private repos, you can use restrictions to specific users / user groups.

How to use above artefacts:

a. create a service depending on the library.

b. add remote repository attributes at pom.xml, specifying which remote repository where you can find above artefact.

c. in case your artefact is public, mvn compile or any of the goals should be able to download the dependency, a jar in our case.

d. for a private build artefact, we need to create a github access token with read-packages permission at least, so that we can use to download artefact.

e. with the gitub access token, updated in your settings.xml with id param matching with that of the remote repository tag, and provided you have access t the repo (at least read), mvn compile or similar goal should help you download the artefact.

1. S3 backed build artefact registry

   We can use AWS S3 storage service to also store our artefacts securely. This helps you to maintain control over your artefacts in a finer way by specifying access policy, either limiting by VPC, or any other IAM policy.

   Also, you can make it region specific, or have a S3 policy retrictive to same VPC as your build tool (like goCD, jenkins) so only your pipeline can build it. For local build, VPN to the VPC could help. This makes access secure, finer control over visibility to package and no modification for settings.xml.

   1. For deploying artefacts to S3 bucket, we need a special dependency, namely maven-s3-wagon, this allows you to deploy maven artefact to s3 bucket.
   2. Add distributionManagement attributes to your project object mode file, pom.xml specifiying which s3 bucekt you want your code to be put into. (we can have only single distributionManagement repo, at max 2 for snapshot and release separately)
   3. Do mvn deploy to deploy your artifact as a dependency.
   4. You should see your artifact deployed in corresponding package.
   5. Restrict the use of artefact by making your repo private, or you can keep it public. for private repos, you can use restrictions to specific users / user groups.

   For using above artefact:

   1. specify your artefact s3 registry in remote repositories tag (we can have multiple remote repositories)
   2. if your AWS credentials are configured, you should be able to download the dependencies , for mvn compile.

Both approaches are good enough with a little bit of tradeoff.
Github Registry is free and control can be given to specific users/ groups with read and write access.

Same For S3 bucket as registry, where you can control access via Virtual Private Network, to only some instances and maybe to some resources, principles.
S3 services depends on your AWS usage, but it is very inexpensive.

Comparing approaches

• Github Registry puts your artefact closer to your code and has better visibility from code perspective. All code and dependency at one place.

• While S3, gives you better security if you want existing IAM roles, policies applied to your artefacts as well.

• Github Registry will throw error if you do not have write access while pushing or if above version already exists.

• S3 Bucket will allow a authorizied push but overwrites previous artefact with same version.

• You can check previous artefact in S3 bucket versions section, but it won't be downloadable by user directly.
  This could be a major flaw if somebody tried to update same version. Could affect all users at once.

Both are highly available, and well performing service managing different versions, and proper updates being update.