Remove hard-wired instances of "master"

Closes #375

Author: jennybc

.github/CONTRIBUTING.Rmd

@@ -19,7 +19,7 @@ output:
     - GOOD PR title: "Obtain user's intent via mind-reading; fixes #86".
     - BAD PR title: "Fixes #1043". Please remind us all what issue #1043 is about!
     - BAD PR title: "Something about #345". This will not actually close issue #345 upon merging. [Use the magic words](https://help.github.com/articles/closing-issues-using-keywords/).
-  * Add a bullet to `NEWS.md` with a concise description of the change, if it's something a user would want to know when updating the package. [dplyr's `NEWS.md`](https://github.com/tidyverse/dplyr/blob/master/NEWS.md) is a good source of examples. Note the sentence format, the inclusion of GitHub username, and links to relevant issue(s)/PR(s). We will handle any organization into sub-sections just prior to a release. What merits a bullet?
+  * Add a bullet to `NEWS.md` with a concise description of the change, if it's something a user would want to know when updating the package. [dplyr's `NEWS.md`](https://github.com/tidyverse/dplyr/blob/main/NEWS.md) is a good source of examples. Note the sentence format, the inclusion of GitHub username, and links to relevant issue(s)/PR(s). We will handle any organization into sub-sections just prior to a release. What merits a bullet?
     - Fixing a typo in the docs does not, but it is still awesome and deeply appreciated.
     - Fixing a bug or adding a new feature is bullet-worthy.
 
@@ -61,7 +61,7 @@ For small changes, it's fine to test your specific change locally and make a PR.
 
 #### Auth
 
-A token is put into force at the beginning of a test run by the first few lines of [tests/testthat/helper.R](https://github.com/tidyverse/googledrive/blob/master/tests/testthat/helper.R).
+A token is put into force at the beginning of a test run by the first few lines of [tests/testthat/helper.R](https://github.com/tidyverse/googledrive/blob/main/tests/testthat/helper.R).
 
   * This reflects the approach documented in the gargle vignette [Managing tokens securely](https://gargle.r-lib.org/articles/articles/managing-tokens-securely.html). We use embedded, encrypted service account token.
   * If you want to use a token you already have, edit those lines to use any of the techniques described in the gargle vignette [Non-interactive auth](https://gargle.r-lib.org/articles/non-interactive-auth.html). Don't commit and submit this change as part of a pull request; just use it as a pragmatic way to run tests with a token you have on hand.
@@ -123,7 +123,10 @@ Note that the current user is appended! This is so that concurrent test runs do
 
 ### Continuous integration
 
-googledrive is checked on the current R release on Windows, via [AppVeyor](https://ci.appveyor.com/project/tidyverse/googledrive), and on several versions of R on Linux, via [Travis CI](https://travis-ci.org/tidyverse/googledrive). We use [codecov](https://codecov.io/github/tidyverse/googledrive?branch=master) to track the test coverage. In general, the package is subjected to `R CMD check`, unit tests, and test coverage analysis after every push to GitHub. There are encrypted service account tokens on both AppVeyor and Travis CI, so tests against the Drive API can be run.
+googledrive is checked on a large matrix of R versions and operating systems via GitHub Actions.
+We use [codecov](https://codecov.io/github/tidyverse/googledrive?branch=main) to track the test coverage.
+In general, the package is subjected to `R CMD check`, unit tests, and test coverage analysis after every push to GitHub.
+For internal branches, an encrypted service account token is available on GHA, so tests against the Drive API can be run.
 
 Things are a bit different for pull requests from outside contributors, however. These PRs do not have access to the encrypted tokens, therefore many tests must be skipped. The PR will still be vetted via `R CMD check` and tests that do not call the Drive API can still be run. After you make a PR, it's a good idea to check back after a few minutes to see all of these results. If there are problems, read the log and try to correct the problem proactively. We "squash and merge" most pull requests, internal or external, so don't agonize over the commit history.
 

.github/CONTRIBUTING.md

@@ -11,70 +11,70 @@ Contributing to googledrive
 
 ## Making a pull request
 
-  - Uphold the design principles and package mechanics outlined below.
-  - When in doubt, discuss in an issue before doing lots of work.
-  - Make sure the package still passes `R CMD check` locally for you.
-    It’s a good idea to do that before you touch anything, so you have
-    a baseline.
-  - Match the existing code style. Our intent is to follow
+-   Uphold the design principles and package mechanics outlined below.
+-   When in doubt, discuss in an issue before doing lots of work.
+-   Make sure the package still passes `R CMD check` locally for you.
+    It’s a good idea to do that before you touch anything, so you have a
+    baseline.
+-   Match the existing code style. Our intent is to follow
     <https://style.tidyverse.org>. Please use the [styler
     package](https://styler.r-lib.org) to re-style any code that you
     touch.
-  - Tests: please *try* to run our tests or at least those that exercise
+-   Tests: please *try* to run our tests or at least those that exercise
     your PR. Add tests, if relevant. If things go sideways, just say so.
     We are painfully aware that it’s not easy to test API-wrapping,
     auth-requiring packages like googledrive and are open to
     constructive feedback. More below.
-  - Documentation: Update the documentation source, if your PR changes
+-   Documentation: Update the documentation source, if your PR changes
     any behavior. We use
     [roxygen2](https://cran.r-project.org/package=roxygen2), so you must
     edit the roxygen comments above the function; never edit `NAMESPACE`
     or `.Rd` files by hand. More below.
-  - Website: The pkgdown-created website is built and deployed
+-   Website: The pkgdown-created website is built and deployed
     automatically via Travis-CI. Some changes require an edit to the
     `reference` section of `_pkgdown.yml`, i.e. to make sure that a
     function appears there.
-  - If the PR is related to an issue, link to it in the description,
+-   If the PR is related to an issue, link to it in the description,
     with [the `#15`
     syntax](https://help.github.com/articles/autolinked-references-and-urls/)
     and the issue slug for context. If the PR is meant to close an
     issue, make sure one of the commit messages includes [text like
-    `closes #44` or `fixes
-    #101`](https://help.github.com/articles/closing-issues-using-keywords/).
+    `closes #44` or
+    `fixes #101`](https://help.github.com/articles/closing-issues-using-keywords/).
     Provide the issue number and slug in the description, even if the
     issue is mentioned in the title, because auto-linking does not work
     in the PR title.
-      - GOOD PR title: “Obtain user’s intent via mind-reading; fixes
-        \#86”.
-      - BAD PR title: “Fixes \#1043”. Please remind us all what issue
-        \#1043 is about\!
-      - BAD PR title: “Something about \#345”. This will not actually
-        close issue \#345 upon merging. [Use the magic
+    -   GOOD PR title: “Obtain user’s intent via mind-reading; fixes
+        #86”.
+    -   BAD PR title: “Fixes #1043”. Please remind us all what issue
+        #1043 is about!
+    -   BAD PR title: “Something about #345”. This will not actually
+        close issue #345 upon merging. [Use the magic
         words](https://help.github.com/articles/closing-issues-using-keywords/).
-  - Add a bullet to `NEWS.md` with a concise description of the change,
+-   Add a bullet to `NEWS.md` with a concise description of the change,
     if it’s something a user would want to know when updating the
     package. [dplyr’s
-    `NEWS.md`](https://github.com/tidyverse/dplyr/blob/master/NEWS.md)
-    is a good source of examples. Note the sentence format, the
-    inclusion of GitHub username, and links to relevant issue(s)/PR(s).
-    We will handle any organization into sub-sections just prior to a
-    release. What merits a bullet?
-      - Fixing a typo in the docs does not, but it is still awesome and
+    `NEWS.md`](https://github.com/tidyverse/dplyr/blob/main/NEWS.md) is
+    a good source of examples. Note the sentence format, the inclusion
+    of GitHub username, and links to relevant issue(s)/PR(s). We will
+    handle any organization into sub-sections just prior to a release.
+    What merits a bullet?
+    -   Fixing a typo in the docs does not, but it is still awesome and
         deeply appreciated.
-      - Fixing a bug or adding a new feature is bullet-worthy.
+    -   Fixing a bug or adding a new feature is bullet-worthy.
 
 ## Package philosophy
 
-  - When in doubt, take a cue from the Unix file system commands or the
+-   When in doubt, take a cue from the Unix file system commands or the
     Google Drive browser UI.
-  - Have a reasonable default whenever humanly possible. This applies to
+-   Have a reasonable default whenever humanly possible. This applies to
     auth, file name, file location, etc.
-  - Be pipe-friendly.
-  - If it’s not well-documented (e.g. working example\!), it doesn’t
+-   Be pipe-friendly.
+-   If it’s not well-documented (e.g. working example!), it doesn’t
     really exist.
-  - Accommodate initial file specification via path or name, but
+-   Accommodate initial file specification via path or name, but
     constantly push downstream work to be based on file id.
-  - Return a tidy tibble, almost always a
+-   Return a tidy tibble, almost always a
     [`dribble`](https://tidyverse.github.io/googledrive/reference/dribble.html),
     whenever it makes sense.
 
@@ -96,7 +96,7 @@ do things we haven’t made available in the high-level interface.
 
 We use [roxygen2](https://cran.r-project.org/package=roxygen2),
 specifically with the [Markdown
-syntax](https://roxygen2.r-lib.org/articles/rd-formatting.html),
+syntax](https://cran.r-project.org/web/packages/roxygen2/vignettes/markdown.html),
 to create `NAMESPACE` and all `.Rd` files. All edits to documentation
 should be done in roxygen comments above the associated function or
 object.
@@ -132,13 +132,13 @@ googledrive.
 
 A token is put into force at the beginning of a test run by the first
 few lines of
-[tests/testthat/helper.R](https://github.com/tidyverse/googledrive/blob/master/tests/testthat/helper.R).
+[tests/testthat/helper.R](https://github.com/tidyverse/googledrive/blob/main/tests/testthat/helper.R).
 
-  - This reflects the approach documented in the gargle vignette
+-   This reflects the approach documented in the gargle vignette
     [Managing tokens
     securely](https://gargle.r-lib.org/articles/articles/managing-tokens-securely.html).
     We use embedded, encrypted service account token.
-  - If you want to use a token you already have, edit those lines to use
+-   If you want to use a token you already have, edit those lines to use
     any of the techniques described in the gargle vignette
     [Non-interactive
     auth](https://gargle.r-lib.org/articles/non-interactive-auth.html).
@@ -157,18 +157,17 @@ test run also creates and destroys files, both locally and on Drive, but
 that is different and not what we’re talking about here.
 
 1.  Source `tests/testthat/driver.R` to extract and aggregate the
-    current setup and clean code across all test
-    files.
-    
+    current setup and clean code across all test files.
+
     ``` r
     ## gather all the test setup and clean code from individual test files
     source(testthat::test_path("driver.R"))
     ## leaves behind:
     ##   * all-test-setup.R
     ##   * all-test-clean.R
     ```
-    
-      - This creates two R scripts: `tests/testthat/all-test-setup.R`
+
+    -   This creates two R scripts: `tests/testthat/all-test-setup.R`
         and `tests/testthat/all-test-clean.R`. Inspect them.
 
 2.  When you are truly ready to perform setup or clean, edit the code to
@@ -179,8 +178,6 @@ that is different and not what we’re talking about here.
 3.  Render `all-test-setup.R` with the Knit button in RStudio or like
     so:
 
-<!-- end list -->
-
 ``` r
 rmarkdown::render(testthat::test_path("all-test-setup.R"))
 ```
@@ -193,7 +190,7 @@ You should now be able to run the tests via *Build \> Test Package* or
 
 You can leave the setup in place for as long as you’re working on
 googledrive, i.e. you don’t need to do this for every test run. In fact,
-that is the whole point\!
+that is the whole point!
 
 When your googledrive development is over, render the clean script:
 
@@ -203,21 +200,21 @@ rmarkdown::render(testthat::test_path("all-test-clean.R"))
 
 Again, read the report to look over what happened, in case anything was
 trashed that should not have been (btw, let us know about that so we can
-fix\!). Once you’re satisfied that your own files were not touched, you
+fix!). Once you’re satisfied that your own files were not touched, you
 can `drive_empty_trash()` to truly delete the test files.
 
 #### Adding tests
 
 If you’re going to add or modify tests, follow these conventions:
 
-  - Test files are marked up with knitr chunk headers in comments, e.g.
-    `# ---- clean ----` or `# ---- tests ----`. This is what enables the
-    `driver.R` script to isolate the setup or cleaning code. Don’t break
-    that.
-  - Any file that is truly necessary and can be setup in advance and
+-   Test files are marked up with knitr chunk headers in comments,
+    e.g. `# ---- clean ----` or `# ---- tests ----`. This is what
+    enables the `driver.R` script to isolate the setup or cleaning code.
+    Don’t break that.
+-   Any file that is truly necessary and can be setup in advance and
     persist? Do it, in order to make future test runs faster. Put the
     associated setup and clean code at the top of the test file.
-  - All test files should have a name that documents why they exist and
+-   All test files should have a name that documents why they exist and
     who made them. Use the `# ---- nm_fun ----` chunk to define naming
     functions used in that test file (see existing files for examples).
     Always use one of these functions to generate file names. Use
@@ -236,28 +233,26 @@ file:
     DESCRIPTION-TEST-drive-upload-travis
     <informative-slug>-TEST-<test-context>-<user>
 
-Note that the current user is appended\! This is so that concurrent test
+Note that the current user is appended! This is so that concurrent test
 runs do not attempt to edit the same files.
 
 ### Continuous integration
 
-googledrive is checked on the current R release on Windows, via
-[AppVeyor](https://ci.appveyor.com/project/tidyverse/googledrive), and
-on several versions of R on Linux, via [Travis
-CI](https://travis-ci.org/tidyverse/googledrive). We use
-[codecov](https://codecov.io/github/tidyverse/googledrive?branch=master)
-to track the test coverage. In general, the package is subjected to `R
-CMD check`, unit tests, and test coverage analysis after every push to
-GitHub. There are encrypted service account tokens on both AppVeyor and
-Travis CI, so tests against the Drive API can be run.
+googledrive is checked on a large matrix of R versions and operating
+systems via GitHub Actions. We use
+[codecov](https://codecov.io/github/tidyverse/googledrive?branch=main)
+to track the test coverage. In general, the package is subjected to
+`R CMD check`, unit tests, and test coverage analysis after every push
+to GitHub. For internal branches, an encrypted service account token is
+available on GHA, so tests against the Drive API can be run.
 
 Things are a bit different for pull requests from outside contributors,
 however. These PRs do not have access to the encrypted tokens, therefore
-many tests must be skipped. The PR will still be vetted via `R CMD
-check` and tests that do not call the Drive API can still be run. After
-you make a PR, it’s a good idea to check back after a few minutes to see
-all of these results. If there are problems, read the log and try to
-correct the problem proactively. We “squash and merge” most pull
+many tests must be skipped. The PR will still be vetted via
+`R CMD check` and tests that do not call the Drive API can still be run.
+After you make a PR, it’s a good idea to check back after a few minutes
+to see all of these results. If there are problems, read the log and try
+to correct the problem proactively. We “squash and merge” most pull
 requests, internal or external, so don’t agonize over the commit
 history.
 

R/camelCase.R

@@ -1,5 +1,5 @@
 # camelCase() and toCamel() taken from
-# https://github.com/rstats-db/bigrquery/blob/master/R/camelCase.R
+# https://github.com/r-dbi/bigrquery/blob/main/R/camelCase.R
 
 # in theory, belongs in gargle
 # but then we'd need to export it and I'm not sure it's worth it

README.Rmd

@@ -33,7 +33,7 @@ googledrive::drive_deauth()
 <!-- badges: start -->
 [![CRAN status](https://www.r-pkg.org/badges/version/googledrive)](https://CRAN.R-project.org/package=googledrive)
 [![R-CMD-check](https://github.com/tidyverse/googledrive/workflows/R-CMD-check/badge.svg)](https://github.com/tidyverse/googledrive/actions)
-[![Codecov test coverage](https://codecov.io/gh/tidyverse/googledrive/branch/master/graph/badge.svg)](https://codecov.io/gh/tidyverse/googledrive?branch=master)
+[![Codecov test coverage](https://codecov.io/gh/tidyverse/googledrive/branch/main/graph/badge.svg)](https://codecov.io/gh/tidyverse/googledrive?branch=main)
 <!-- badges: end -->
 
 ## Overview