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

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?

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.

StackExchange DevOps Q#5108, answer score: 12