Till now I had used the fairly easy to understand deployment strategy of uploading to transfer.sh, downloading from there, and then manually uploading to create github releases.
after_success:
- curl --upload-file GL_warp2mp4*.AppImage https://transfer.sh/GL_warp2mp41.10-x86_64.AppImage
Appveyor has its artifacts page, so a similar strategy works there.
But a couple of days back, transfer.sh was (temporarily) down, so deploying directly to github from travis seemed attractive.
But did not get it to work, until now. Some notes -
edge: true
after_success:
- curl --upload-file GL_warp2mp4*.AppImage https://transfer.sh/GL_warp2mp41.10-x86_64.AppImage
Appveyor has its artifacts page, so a similar strategy works there.
But a couple of days back, transfer.sh was (temporarily) down, so deploying directly to github from travis seemed attractive.
But did not get it to work, until now. Some notes -
- Directly entering github personal tokens in a commit on github results in github immediately revoking the token.
- Travis has rolled out v2 of their deployment code, but maybe still needs the edge: true directive to reliably use v2 instead of v1.
- Currently working code is here. The environment variable mytokenname has to be set in the project's settings on travis.
- The draft setting ensures that the deployment is visible only to me - I can edit the draft and create a release. Also, because of this, when I create a release, that commit does not create a new deployment in an infinite loop.
- The file_glob setting allows the use of wildcards in the file option.
deploy: |
provider: releases |
token: $mytokenname |
file_glob: true |
file: h*.bin |
skip_cleanup: true |
draft: true |
after_success: |
No comments:
Post a Comment