I have a few open source projects that I manage. I've been posting the .tar.gz releases for them to a directory on a webserver I run. I would like to post them to github. Is there a simple way to post the release and a signature for the release? My users aren't sophisticated enough to download the release with git; they want to download and install a .tar.gz file. Some of them may even want to verify the signature.
GitHub have just announced their new "GitHub Releases" feature, which sounds like exactly what you're after:
https://github.com/blog/1547-release-your-software
One nice option github supports is tagging, and automatic tar.gz/zip creation based on those tags. It makes publishing releases really easy.
http://learn.github.com/p/tagging.html
On the commit/branch that you'd like to mark as a release, do
git tag <release_tag>
then
git push --tags
then, on github.com/user/repo/tags, you can see all tagged releases. You can link straight to those files, like in jimw's answer.
Other awesome option might be distributing from http://bintray.com. It integrates great with GitHub and gives you so much more when distributing binaries.
I you'd also like to upload other kinds of files (compiled binaries, ...) and edit github releases from the commandline with a rather easy-to-use tool, I made something for that. It's called github-release. It's basically a user-friendly abstraction over the Github releases API. It's written in Go so I took the liberty of cross-compiling it for OSX/linux/windows/FreeBSD, and you can download the binaries from the releases page, of course.
DISCLAIMER: I am the author.
You can fetch a tarball of any tag like so:
https://github.com/visionmedia/express/tarball/2.5.4
There are a few utilities to do what you need.
github_upload (Ruby) : https://github.com/github/upload
App::gh (Perl) : https://metacpan.org/module/App::gh::Command::Upload
Take your pick :)
Check out the GitHub Downloads section - no need for git at all to download files from there.
Related
I am an admin for the PIO project (https://github.com/NCAR/ParallelIO), a set of C/Fortran libraries which is built with autoconf/automake/libtool.
When I do a release, GitHub generates a tarball and a zip file of the repo. These are useless because they have not been generated by "make dist" which puts together the actual tarball.
I can add the actual tarball to the release page - is there any way to remove the broken ones that GitHub puts there? As it is, I just tell users not to use those, but that's not a great solution.
Another solution, used on some projects, is to commit the autotools-generated files to the release branch, so that GitHub releases are functional. That seems lame but might be the best option.
I am working on a website and a game server, I want to use github version control but I don't really have any files to upload to github and when I do a release, it also releases the files.
How can I use the version control when I don't have any files to upload...? Or is there any better site for this?
You can initialize an small GitHub repo (with just a README) and use GitHub Release in order to:
make a tag (even if the sources have not change)
upload a binary associated to that tag: see "Creating Releases"
But don't abuse that feature: if you upload files too big, too often, that repo might be invalidated by GitHub support.
We recently moved from subversion to git, and then to Github, for several open source projects. Github was nice in that it provided a lot of functionality. One of the things I particularly like is the ability to download tags as zip or .tar.gz files.
Unfortunately Github recently discontinued downloads. That shouldn't be a problem because of the ability to download tags. However in the past we have not put a Makefile , configure script or any other autoconf-generated files into the repo because they get lots of conflicts when people merge.
What's the proper way to handle this?
Should I put autoconf and automake-generated files in the repo so people can download tags directly?
Or should there be a bootstrap.sh file and people are told to run that?
Or should I just do a make dist and put that into the repo?
Thanks
Publish the output of make dist via GitHub Releases
Your first option—putting the Autoconf- and Automake-generated files into the repository—is not a good idea. It's almost never beneficial to store generated files in source control. In this case, it's going to pollute your history with a lot of unnecessary and potentially conflicting commits, particularly if not all your contributors are using the same version of Autotools. Your third option—checking in the output of make dist—is a bad idea for exactly the same reasons as the first option.
Your second option—adding a "bootstrap" script that calls Autoconf and Automake to generate the configure scripts—is also a bad idea. This defeats the entire purpose of Autotools, which is to make your source portable across systems—including those for which Autotools is not available! (Consider what would happen if someone wanted to build and install your software on a machine on which they don't have root access, and where the GNU Build System is not installed. A bootstrap script is not going to help them because they'd first need to make a local installation of Autotools and possibly all its dependencies.)
The proper way of releasing code that uses Autotools is to produce a tarball with make dist (or better yet, make distcheck, since this will also run tests and do other sanity checks), and then publish this tarball somewhere other than the source repository.
Your original question, from April 2013, states that GitHub discontinued download pages. However, in July 2013, GitHub added a "Releases" feature that not only pre-packages your source tags, but also allows you to attach arbitrary files to each release. So on GitHub, the Releases page is where you should publish your make dist tarballs (and preferably also the detached GnuPG signatures of them).
Basic steps
When you are ready to make a release, tag it and push the tag to GitHub:
$ git tag 1.0 # Also use -s if desired
$ git push --tags
Use your Makefile to produce a tarball:
$ make dist # Alternatively, 'make distcheck'
Visit the GitHub page for your project and follow the "releases" link:
You will be taken to the Releases page for your project. The first time you visit, all you will see is a list of tags and automatically produced tarballs from the source tree:
Press the "Draft a new release" button.
You will then be presented with a form in which you should fill in the Git tag associated with the release and an optional title and description. Below this there is also a file selector labelled "Attach binaries by dropping them here or selecting them". Use this to upload the tarball you created in Step 2 (and maybe also a detached GnuPG signature of it).
When you're done, press the "Publish release" button.
Your project's Releases page will now display the release, including prominent download links for the attached files:
If you don't want to use GitHub Releases, then as pointed out in a previous answer, you should upload the tarballs somewhere else, such as your own website or FTP site. Add a link to this repository from your project's README.md so that users can find it.
The second is better: you want any user of your repo to be up and running as fast as possible, re-generating what he/she needs in order to build your program.
Since Git is very much a version control for text (as opposed to an artifact repo like Nexus), providing a way to generate the final binary is the way to go.
When you cut a release, upload the result of make distcheck to your project's download page: it's a makefile target that builds the tarball and verifies that it installs, uninstalls, passes tests and other sanity checks. Github being wrong-headed isn't an excuse: create a tree like this in your repo:
/
/source
/source/configure.ac
/source/Makefile.am
/source/...
/releases
/releases/foo-0.1.tar.gz
/releases/...
For developers, you should not have generated files in source control. Many modern autotooled projects bootstrap fine off an invocation of autoreconf -i.
I want allow users to download executable of one of my project on github, without downloading all sources or browsing the entire project.
According to this similar question, you could use a upload/download service, which apparently, github has shut down.
So is there another way? Is github aiming at sharing code only, not software?
Update 2d July 2013, you now can define a release.
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.
This is what replaces the old binary upload service, which was removed in December 2012!
Ideally, you would store your executable in an artifact repository, as opposed as a source repository like GitHub.
So yes, GitHub is for source control management, not deliveries (like binaries produced from your code).
Nexus is the usual choice for any generated artifacts like binaries, with a free upload possibility for open-source projects.
See "How do I get my software into Central?" (from this answer, also mentioned in "Maven repository hosting for non-public artifacts?")
You can create another repository to host all your builds , I mean executable files . With in that repository don't add any of your code other than your builds ,
As a result of this , people can click on download Zip button at git hub , which downloads only executable ( as a zip file ).
while building you can copy the executable file in a folder just push to remote repository which is hosting only builds .
Hope this helps .
basically , GIT is just an SCM ( source code management system ) it is not meant for this purpose .
but still this how you can utilize the service of github.org amd git .
hope this helps .
EDIT : -
Git hub now has a solution for hosting releases it has been well explained by #VonC in the post below . Please use that as a solution.
The following worked for me, YMMV. On a MAC and using Chrome browser, after getting to this page I clicked on the "Raw" button (the "View Raw" link also worked), and it downloaded the executable tatuMicro.kit to my Downloads folder
An exe file can be hosted under releases and the link can be distributed among friends etc. I tested it as recently as yesterday. Only issue is if someone sabotages the program for profit. The exe files can be moved around and distributed easily on pendrives.
I've realised that the java project I'm working on is affected by this bug: jsoup Google Groups
I don't think this sort of question is really suitable for posting in the group discussion and I don't really want to sit and wait for the next release so could somebody be kind enough to explain what implementing this fix ASAP would entail? How does one build from the trunk of the project?
Just to be clear, I would be looking to end up with a patched version of the jsoup .jar for inclusion in my project.
Thanks as always!
The reply I got from on #git IRC:
jsoup github download link
You can either use git to archive the repository, or use github's download functionality. After which you will need to compile the jar from the source there. If you choose to use github, when you click download pick either of the .tar.gz or .zip buttons next to "Branch: master"
Lesson learnt: Try IRC first!