2.x: Automatically publish the generated JavaDocs from CI #5996
Conversation
Codecov Report
@@ Coverage Diff @@
## 2.x #5996 +/- ##
===========================================
+ Coverage 98.25% 98.3% +0.04%
- Complexity 6051 6052 +1
===========================================
Files 656 656
Lines 44078 44078
Branches 6118 6118
===========================================
+ Hits 43311 43330 +19
+ Misses 231 220 -11
+ Partials 536 528 -8
Continue to review full report at Codecov.
|
|
PRs don't trigger: https://travis-ci.org/ReactiveX/RxJava/builds/375403314#L4010 Branches do trigger: https://travis-ci.org/ReactiveX/RxJava/builds/375403308#L4018 |
.travis.yml
Outdated
| @@ -20,6 +20,7 @@ script: gradle/buildViaTravis.sh | |||
| # Code coverage | |||
| after_success: | |||
| - bash <(curl -s https://codecov.io/bash) | |||
| - bash gradle/push.sh | |||
gradle/push.sh
Outdated
|
|
||
| # commit all | ||
| echo -e "commit Travis build: $TRAVIS_BUILD_NUMBER for $buildTag" | ||
| git commit --message "Travis build: $TRAVIS_BUILD_NUMBER for $buildTag" |
There was a problem hiding this comment.
Should we include in the message that I'll update the documentation?
There was a problem hiding this comment.
I don't think there is much ambiguity. These go into the gh-pages tab: https://github.com/ReactiveX/RxJava/tree/gh-pages
|
Looks like the release mode also works: |
This PR adds a script that publishes the generated JavaDocs from CI back to the
gh-pagesbranch upon successful snapshot and release builds (this latter needs testing though via -RC releases).The snapshot JavaDocs will go into the same directory: http://reactivex.io/RxJava/2.x/javadoc/snapshot/
The release builds update
rxlinks,The
push.shscript uses a Travis-CI secured tokenGITHUB_TOKENto talk to the GitHub API. This token was created for my account via https://github.com/settings/tokens (requires repo direct push access), and provided to Travis via "Environment variables" on the page https://travis-ci.org/ReactiveX/RxJava/settings .If, for some reason the publishing fails, the build still counts as successful. The reason for this is that restarting the otherwise successful build will try to reupload the same library version into maven which fails. In this case, the JavaDocs can be updated via the old manual method.