Deploy to GitHub branch

[krlmlr]

How about adding one or two verbs that simplify deploying to a GitHub branch? It seems that currently this is the only solution that does not require registration with another provider (Dropbox, S3, ...).

An implementation is available at https://github.com/luckyrandom/r-deploy-git .

@luckyrandom: Would you be interested?

[luckyrandom]

Sure, I'm interested in that.

Do you mean deploy binary files to github, or deploy source pkgs with files generated by roxygen, Rcpp or some other tools?

[krlmlr]

Both would be of interest, actually, so perhaps it'd be good to make this generic, with an argument. One particular use case is the deployment of binary OS X packages.

[luckyrandom]

While trying to implement it, I found out that github has some kind of support for release https://help.github.com/categories/85/articles . However, it enforce usage of tags and the api is too complex to call in bash. Travis has some support for github release, but it's quite limited.

Certainly, we can just upload the pkgs in a branch, as I did in https://github.com/luckyrandom/r-deploy-git, but it may not be a good idea to track binary files in git, especially considering that github support binary files in release.

[krlmlr]

I don't think we should publish one release for each Travis-CI build. Once per "stable" version would be fine, the question remains how to detect such a stable version. Perhaps if Travis-CI is running against a tagged revision which doesn't have an associated release yet? -- There is rgithub, but I don't know if it already provides access to the Releases API.

You're probably right -- polluting the repo with binaries, even in a different branch, probably is a bad idea too. When cloning, I assume that also the unrelated branches will be fetched by default.

[luckyrandom]

I was able to implement some github release support in my forked repository, https://github.com/luckyrandom/r-travis . The main code is in github-release.rb, since rgithub doesn't support Releases API yet. Currently, it handles release in the following way,

• If [try deploy github] is found in single line in commit message, it will create a github release with version number from DESCRIPTION. Github will invoke another build on travis-ci for the release.
• If the travis-ci build is for a release, it attached pkg files to the release. It assumes the pkg files have already been created by some other scripts.

When a package is ready for release, the maintainer just need to push a commit with [try deploy github], and travis-ci will create release and attach package automatically. Please see https://github.com/luckyrandom/r-travis-test for a simple demo.

Actually, with options --bump-version github-release.rb can bump version automatically if the version is provided in form a.b.*. But I don't know what is a reasonable workflow for auto bumped version.

[krlmlr]

This is awesome! How do you detect in Travis-CI that the build is for a release?

Would this also work for releases that are created manually? This would perhaps simplify the process.

[luckyrandom]

Travis define ${TRAVIS_TAG} when the build is for a tag, and we can use github api to check whether it's associated with a release. Actually, if the tag is not a release, my script will create a release automatically, when the tag looks like v3.2.2. I'm not quite sure that's the right behavior.

Yes. It supports release created manually, and tags pushed to github, if the tag name looks like a version number . Both of them will trigger a travis build for tag, so the pkgs are uploaded.

There are still a few small issues to fix. You can expect a pull request in the next few days, if this is the workflow we want.

[krlmlr]

This sounds great, I wasn't aware your code supported this. Personally, I use tags of the form x.y-z, so we might want to be a more flexible when detecting revision numbers.

How difficult would it be to implement this functionality in R, if rgithub supported releases?