Merge pull request #756 from imageworks/codecov-workflow-v3

Codecov workflow v3 and branch rename

Author: jrray

.github/workflows/coverage.yml

@@ -6,7 +6,7 @@ on:
       - "crates/**.rs"
   push:
     branches:
-      - master
+      - main
     paths:
       # Only run coverage report if the sources have changed
       - "src/**.rs"
@@ -53,6 +53,6 @@ jobs:
           # this feature is enabled.
           spfs run - -- bash -c 'cargo tarpaulin --features migration-to-components --workspace --verbose --timeout 120 --out Xml'
       - name: Upload to codecov.io
-        uses: codecov/codecov-action@v2
+        uses: codecov/codecov-action@v3
         with:
           token: ${{ secrets.CODECOV_TOKEN }}

CONTRIBUTING.md

@@ -113,7 +113,7 @@ repos private (prior to announced public release of the open source project), pl
 3. Edit, compile, and test your changes in a topic branch:
 
    ```
-   $ git checkout -b mytopic master
+   $ git checkout -b mytopic main
    $ ... do your edits ...
    ```
 
@@ -141,4 +141,4 @@ committed. Sometimes this takes a few rounds of give and take. Please don't
 take it hard if your first try is not accepted. It happens to all of us.
 
 8. After approval, one of the senior developers (with commit approval to the
-official main repository) will merge your fixes into the master branch.
+official main repository) will merge your fixes into the main branch.

README.md

@@ -209,15 +209,15 @@ cargo bench --bench spfs_bench
 A common workflow as described [here](https://bheisler.github.io/criterion.rs/book/user_guide/command_line_options.html#baselines) is to record a baseline measurement to use as a reference to compare future measurements to.
 
 ```sh
-git checkout master
-# Record baseline with name "master"
-cargo bench --bench spfs_bench -- --save-baseline master
+git checkout main
+# Record baseline with name "main"
+cargo bench --bench spfs_bench -- --save-baseline main
 
 git checkout topic-branch
 # While iterating, this creates a new baseline called "new", and
 # will report on the change since the most recent "new".
 cargo bench --bench spfs_bench
 
-# Compare to "master"
-cargo bench --bench spfs_bench -- --load-baseline new --baseline master
+# Compare to "main"
+cargo bench --bench spfs_bench -- --load-baseline new --baseline main
 ```

docs/use/_index.md

@@ -34,7 +34,7 @@ $ spk env --local my-pkg
 ```
 
 Use the [Package Definition Guide](spec) for more details.
-Check the included [examples](https://github.com/imageworks/spk/tree/master/examples) for additional help.
+Check the included [examples](https://github.com/imageworks/spk/tree/main/examples) for additional help.
 
 For more detailed information on the build process, check the [Package Build Process](build)
 

docs/use/spec.md

@@ -93,7 +93,7 @@ You can include sources from mulitple location, but will need to specify a subdi
 sources:
   # clones this git repo into the 'someproject' subdirectory
   - git: https://github.com/someuser/someproject
-    ref: master
+    ref: main
     subdir: someproject
     # copies the contents of the spec file's location into the 'src' subdirectory
   - path: ./

packages/openimageio/openimageio.spk.yaml

@@ -7,13 +7,13 @@ api: v0/package
   # - license: BSD-3-clause
   # - bindings: [ "C++", "C", "Python", "cli" ]
 
-# If building off the master/development branch of OIIO, there is no
+# If building off the main/development branch of OIIO, there is no
 # guarantee of API or ABI compatibility (except for the most minor level of
 # patches), so be stricter than usual, with "x.x.a.b". If building from a
 # release branch, however, the usual x.a.b correctly reflects OIIO's
 # compatibility promises for release branches.
 #
-# Also, if using a "master" OIIO, downstream packages should specify it as:
+# Also, if using a "main" OIIO, downstream packages should specify it as:
 #    - pkg: openimageio
 #      fromBuildEnv: Binary
 #

packages/osl/osl.spk.yaml

@@ -7,7 +7,7 @@ api: v0/package
   # - license: BSD-3-clause
   # - bindings: [ "C++", "Python", "cli" ]
 
-# If building off the master/development branch of OSL, there is no
+# If building off the main/development branch of OSL, there is no
 # guarantee of API or ABI compatibility (except for the most minor level of
 # patches), so be stricter than usual, with "x.x.a.b". If building from a
 # release branch, however, the usual x.a.b correctly reflects OSL's