❯ usethis::use_pkgdown_travis()
✔ Setting active project to '/Users/gaborcsardi/works/ps'
✔ Adding 'docs/' to '.gitignore'
● Set up deploy keys by running `travis::use_travis_deploy()`
● Insert the following code in '.travis.yml'
before_cache: Rscript -e 'remotes::install_cran("pkgdown")'
deploy:
provider: script
script: Rscript -e 'pkgdown::deploy_site_github()'
skip_cleanup: true
[Copied to clipboard]This adds /docs to .gitignore and tells you two other steps you
need to do. Our setup here is a bit more complicated, but this is a good
start.
The suggested config will probably work, but I want to use a custom pkgdown branch, and also deploy for git tags. I tend to use this config:
matrix:
include:
- r: 3.2
- r: 3.3
- r: 3.4
- r: 3.5
- r: release
env: R_CODECOV=true
before_cache: Rscript -e 'remotes::install_github("r-lib/pkgdown@fix/examples-dontshow")'
deploy:
provider: script
script: Rscript -e 'pkgdown::deploy_site_github()'
skip_cleanup: true
on:
all_branches: true
condition: '"$TRAVIS_BRANCH" == "pkgdown-travis" || -n "$TRAVIS_TAG"'
- r: devel
- os: osx
osx_image: xcode9.3 #High Sierra
- os: osx
osx_image: xcode8.3 #SierraWe want to deploy the dev version on every push to GitHub, and also
the released versions that correspond to tags. The condition line above
makes sure that we deploy from the selected branch, and also for tags.
Initially you might want to set the branch (like pkgdown-travis here),
to deploy from to a different one, so you don't need to experiment in the
master branch. Once it is working, you can change it to master.
You probably do not need this custom pkgdown version, and you are fine
with 'remotes::install_cran("pkgdown") as usethis suggested above.
Only the r: release build is interesting for pkgdown, you don't need to
add the other R versions and OSes.
Make sure you have
destination: docs
development:
mode: autoin _pkgdown.yml. Other destination and development entries should
be removed, if you had a different setup before.
This is supposed to be simple via travis::use_travis_deploy() (the
travis package is at https://github.com/ropenscilabs/travis). But that has
never worked for me, I am not sure why. We can follow its code manually,
though, and run, from R:
key <- openssl::rsa_keygen()
pub_key <- travis:::get_public_key(key)
private_key <- travis:::encode_private_key(key)Now go to the 'Settings' Travis page of your repo (e.g.
https://travis-ci.org/r-lib/ps/settings) and add the string in
private_key as an environment variable, for all branches. Its name
should be id_rsa. Do not display its value in the logs.
We'll need this private key a bit later, so save it now.
Now go to the GitHub repo of the package to set up the deploy key there. E.g. at https://github.com/r-lib/ps/settings/keys Click on 'Add deploy key', the title can be 'pkgdown from Travis' and the key should be the output of
openssl::write_ssh(pub_key)Make sure you allow write access.
Now remove the /docs directory from your repo. I suggest you create a
new branch, e.g. pkgdown-travis. Make sure that you configure deployment
for this branch in .travis.yml, see the example Travis yaml above.
Then push all changes to GitHub.
Travis will start building the new branch. You can cancel all but one builds in the build matrix, just keep the R-release one, that'll do the deployment.
If everything is OK, Travis deploys the pkgdown site for the dev version
of the package. You can look at the files in the gh-pages branch, e.g.
for the ps package this is at https://github.com/r-lib/ps/tree/gh-pages
You should see a dev directory and in it the pkgdown website.
We still need to deploy the released version. There are various ways to do this, maybe the easiest is to do it from your computer, as you cannot go back in time and change the Travis config of the package at the time of the last release. (Alternatively, you could create a git branch from the last release tag and update the Travis and pkgdown config there, and then let Travis build your pkgdown web site.)
Check out the tag of the latest release from git, e.g. for ps:
git tag
git checkout v1.3.0
Then (temporarily) update the _pkgdown.yml file, to keep the dev version
in /dev and deploy the released version in /. As above, add:
destination: docs
development:
mode: autoWe'll deploy using pkgdown::deploy_site_github(), and this needs a
tarball of the package, so let's build that first, from R:
devtools::build()We'll also need the private key for the deployment, in the id_rsa
environment variable:
Sys.setenv(id_rsa = private_key)Ready to deploy. You'll need to provide the repo slug as well, this is detected on Travis, but not here. E.g.
pkgdown::deploy_site_github(
tarball = "../ps_1.3.0.tar.gz",
repo_slug = "r-lib/ps"
)Now look at the gh-pages branch on GitHub, to make sure that it
has both the released and the dev version of the package.
E.g. at https://github.com/r-lib/ps/tree/gh-pages
You should see a bunch of files and directories, and again the similar
structure in the dev directory.
Now you can go to the setting page of the repo, e.g.
https://github.com/r-lib/ps/settings and set GitHub Pages to the
gh-pages branch.
Double check that the web site is properly deployed. E.g. for the ps package, the released version is at https://ps.r-lib.org/ and the dev version it is at https://ps.r-lib.org/dev/
Now clean up the changes we made in the detached HEAD of the git repo, and go back to our deployment branch:
git checkout -- .
git checkout pkgdown-travis
Update the Travis config to deploy from the master branch, like this, (see full config above):
on:
all_branches: true
condition: '"$TRAVIS_BRANCH" == "master" || -n "$TRAVIS_TAG"'
You can remove the all_branches line if you like. I prefer to keep it,
just in case I want to deploy from another branch in the future. I would
probably forget to add it back then.
Push the pkgdown-travis branch to GitHub, create a pull request for it
and merge it. Once it is merged, Travis should deploy the dev version of
the pkgdown site again.
Thank you very much for this, it is very useful. The only thing is that, after a while, I ran into the following issue:
As I was not sure why I got this, I decided to go with a personal access token instead. Below is what I am currently using:
This suits my needs!
Again, thank you very much for sharing this!