-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deploy to GitHub branch #124
Comments
Sure, I'm interested in that. Do you mean deploy binary files to github, or |
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. |
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. |
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. |
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,
When a package is ready for release, the maintainer just need to push a commit with Actually, with options |
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. |
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. |
This sounds great, I wasn't aware your code supported this. Personally, I use tags of the form How difficult would it be to implement this functionality in R, if |
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?
The text was updated successfully, but these errors were encountered: