what is the best practice of distributing binaries from a github project? [closed]

Question

what is the best practice of distributing binaries from a github project?

I can think of:

• Create a bin folder in your project where you keep a copy of the binaries. However, github is meant to store source code and not binaries Storing large and regularly changing binaries may be expensive qua diskspace and bandwidth?
• Upload a copy of the binaries to the github pages of the project, or use a separate web site for hosting your binaries. However, that is not always feasible, and requires more (hand)work to keep the binaries up to date, I rather want to have the binaries updated automatically or with a single action.

Spirelet

This question is about where to host binaries, and off topic given recommendations on where to host files – Macri

@Macri I read it as a question about how to use github. – Puli

Answer 1

It is clear to me now that it is important not to store binaries in your github project itself. Thus, you will need to store binaries elsewhere. Possible solutions I came across are:

• Store the binaries in a separate submodule (dalores idea). It makes sense to store them in your projects github pages, which you use to host your projects website via github.
• If you have only a few binaries or zip file only, you can upload them to github via Downloads -> Upload a new file. This feature is quite limited though, you cannot put files in structured folders.
• In case of java jar files, there are solutions out there like Nexus for managing your libraries.
• Store the binaries on a completely separate site that you host yourself

Spirelet

Why is it important not to store binaries in your github project itself? – Scissors

your source code is typically under continuous development, having a lot of commits and small changes all the time. Binaries on the other hand are generated builds of stable versions of your code which should never change after being released. And for binaries you would like to have a directory listing all released version, not just the latest version. It's totally the opposite of each other. – Spirelet

GitHub uploads are now deprecated. See github.com/blog/1302-goodbye-uploads – Usufruct

Adding large binary files to your repo will make it take a very long time to download the history. – Defoliant

Answer 2

As of December 11, 2012 the Downloads feature on GitHub is deprecated. The article Distributing large binaries recommends using an external service:

We recommend Amazon S3 for storage paired with CloudFront for serving via CDN, or other services such as SourceForge.

---

However, since 2d July 2013, you now can define a release.

Releases, a workflow for shipping software to end users.
Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts. They're accessible from a repository's homepage:

• Releases are accompanied by release notes and links to download the software or source code.
• Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.
• You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.

Catechin

"github pages" is public. "github releases" requires a github account. :-( – Otherwhere

Yes, github has releases. I've just created my first project, pushed the source code, went to "releases" in the GitHub web UI, created a new release (entered the desired version number, and GitHub turned that into a tag in my repo), and I was able to upload a file with my binaries. GitHub added a TGZ nad ZIP with the sources, so there are three files available for download. Very clean and seamless. Thanks for this topic BTW. Got me on the right track. – Loganiaceous

Answer 3

What kind of binaries? The binaries must have come from source at some point right?

So add the source that builds those binaries as a submodule in git. Then in your build process build those binaries first before building your source. The submodule is kept in sync to a specific version of the source you know that works. You also get the benefit of being able to debug easier since you have the source.

Unless the binaries are images etc, then just store those.

If space is the issue use bitbucket as they have unlimited space.

Conceptacle

I have for example a java library (jar) generated from a java project. I need to store this library such that it is downloadable for the user of the lib without having to built the lib themselves. I also need to store different versions of the jar (1.3.0, 1.3.1, 1.4.0, etc) as development continues. – Spirelet

For jar files can't you store it in nexus and use maven to download dependencies? That is the standard java way. See #3329541 – Conceptacle

Thanks that makes sense. So, at least it is clear that is is better not to store jars and binaries in git itself, but use an external solution. – Spirelet

yeah, it is not a ready-made answer but it pointed me in the right direction. I've put the solutions I came across in a separate answer. – Spirelet