What are reasons for not not using Bitbucket-server for storing artifacts?

Question

I'm working with a company setting up a brand new project, and we're talking about what tools to use for what. I was talking about Artifactory or Nexus for storing built artifacts (APKs in this case), and they asked why they can't just use Bitbucket like they will use for the software, to reduce the number of tools they need to install and maintain.

My initial response was "Source goes in source repo and artifacts go in artifact repo", but that's not actually an answer why or why not. In fact Googling around didn't offer any reasoning either.

ADDING TO THIS: This product is for a regulated industry. That means we need a complete versioned, auditable record of the artifacts built. This is one of the reasons we're looking into this. Also, as I said in some comments but will add here, we will install Bitbucket in a private GCP not accessible by the public, so there are no concerns about others accessing it.

Any input into this? Anything that would bite us later on if we store them in Bitbucket?

Answer 1

Reasons not to store large binaries in a git repository:

• Everbody cloning your repository will download all those binaries, by default. Binaries, if built regularly, tend to consume massive amounts of storage, compared to source code - git cannot compress them, or calculate deltas, to reduce their size.
• git goes to great lengths to make sure history is not lost, it will never delete anything that is part of the history of any ref (branches or tags). That also means that if you later decide to delete old, long-useless binaries due to running out of space, you will find that, while not impossible, very hard indeed.
• One point of proper artifact stores is that they help phasing out outdated or compromised parts. git cannot really do that for you - you'd have to write your own tooling for that - and you will never get rid of the old versions in history.
• The concept of a "commit" does not really apply to binaries. You need operations like "upload" and "download", as they are regularly involved in the build processes of your software (i.e., bundler in the ruby world, or maven in Java). Those builders know how to fetch their 3rd party libraries from artifact repositories easily, and how to upload new versions. They may be convinced to work with a git repository for downloads, but since git has no versioning information, you again need to have your own tooling, specify the commit in which to find that binary manually, or have all binaries ever in use checked out locally. And uploading to a git repository, again, would use your own tooling (creating spurious commits as well).

In total, using git for that is just the wrong tool. If your colleagues are afraid of adding yet another complex tool like Nexus, then at least convince them to use a simple tool instead of git - like some arbitrary (s)ftp/scp repository in a VM somewhere, with https access via a simple webserver.

If you must use git, then at least make sure the build binaries are not committed together with the source code, but in their own part of history. Check out this older answer to see how to create an orphan branch. Those can at least be deleted later, and the binaries themselves removed by garbage collection; and not every client is forced to download all of it all the time.

Answer 2

You can use a Git repository (whether it is hosted on Bitbucket or not) as an artifact repository, but you should be aware that:

• Git was originally made as a version control system for source code, not for (large) binary data, and this is still its main concern. There are extensions that allow working with large files in Git efficiently, e.g. Git LFS, but still: It is not built into the core of Git.
• A proper artifact repository has features that a Git based service cannot easily provide. For example you probably want to delete older snapshot artifacts, an operation Git is not designed for, but what is a core feature of artifact repositories. Some more of such features are described in the answers to the question What is an artifact repository?.

So while you can use Git/Bitbucket as an artifact repository, it's a bit like driving a screw with a hammer instead of a screwdriver.

Answer 3

If you will store apk files inside Bitbucket's repo you need use git or curl it to clone. And if repo private you need have an access to it, size limitation etc.

The Software repository is more comfortable to store binary files. You can create your own mirror of maven, google repos.

Answer 4

You could use bitbucket pipelines to deploy to the download section and keep your artifacts there. Here is an example from their documentation

Answer 5

As others have said, you wouldn't check the binaries into git. But, Bitbucket offers a separate "Downloads" area per-repo. This is a separate area, not part of the git repo. If using Bitbucket Pipelines, you could even automate the deployment to the downloads area, if that suits the workflow.