fix master to main stuff

Signed-off-by: Adrian Cole <[email protected]>

.github/CONTRIBUTING.md

@@ -1,7 +1,7 @@
 # Contributing to Zipkin
 
 If you would like to contribute code, fork this GitHub repository and
-send a pull request (on a branch other than `master` or `gh-pages`).
+send a pull request (on a branch other than `main` or `gh-pages`).
 
 When submitting code, please apply [Square Code Style](https://github.com/square/java-code-styles).
 * If the settings import correctly, CodeStyle/Java will be named Square and use 2 space tab and indent, with 4 space continuation indent.

README.md

@@ -37,7 +37,7 @@ Releases are at [Sonatype](https://oss.sonatype.org/content/repositories/release
 
 ### Library Snapshots
 Snapshots are uploaded to [Sonatype](https://oss.sonatype.org/content/repositories/snapshots) after
-commits to master.
+commits to main.
 
 ### Docker Images
 Released versions of zipkin-otel are published to the GitHub Container Registry

RELEASE.md

@@ -4,7 +4,7 @@ This repo uses semantic versions. Please keep this in mind when choosing version
 
 1. **Alert others you are releasing**
 
-   There should be no commits made to master while the release is in progress (about 10 minutes). Before you start
+   There should be no commits made to main while the release is in progress (about 10 minutes). Before you start
    a release, alert others on [gitter](https://gitter.im/openzipkin/zipkin) so that they don't accidentally merge
    anything. If they do, and the build fails because of that, you'll have to recreate the release tag described below.
 
@@ -78,7 +78,7 @@ export SONATYPE_USER=your_sonatype_account
 export SONATYPE_PASSWORD=your_sonatype_password
 release_version=xx-version-to-release-xx
 
-# now from latest master, create the release. This creates and pushes the MAJOR.MINOR.PATCH tag
+# now from latest main, create the release. This creates and pushes the MAJOR.MINOR.PATCH tag
 ./build-bin/maven/maven_release release-${release_version}
 
 # once this works, deploy the release
@@ -87,6 +87,6 @@ git checkout ${release_version}
 
 # Finally, clean up
 ./mvnw release:clean
-git checkout master
+git checkout main
 git reset HEAD --hard
 ```

build-bin/README.md

@@ -33,7 +33,7 @@ actions and are entirely appropriate to vary per project. Here's an overview:
 ## Test
 
 Test builds and runs any tests of the project, including integration tests. CI providers should be
-configured to run tests on pull requests or pushes to the master branch, notably when the tag is
+configured to run tests on pull requests or pushes to the main branch, notably when the tag is
 blank. Tests should not run on documentation-only commits. Tests must not depend on authenticated
 resources, as running tests can leak credentials. Git checkouts should include the full history so
 that license headers or other git analysis can take place.
@@ -55,10 +55,10 @@ Here's a partial `test.yml` including only the aspects mentioned above.
 on:
   push:
     tags: ''
-    branches: master
+    branches: main
     paths-ignore: '**/*.md'
   pull_request:
-    branches: master
+    branches: main
     paths-ignore: '**/*.md'
 
 jobs:
@@ -76,13 +76,13 @@ jobs:
 
 ## Deploy
 
-Deploy builds and pushes artifacts to a remote repository for master and release commits on it. CI
-providers deploy pushes to master on when the tag is blank, but not on documentation-only commits.
+Deploy builds and pushes artifacts to a remote repository for main and release commits on it. CI
+providers deploy pushes to main on when the tag is blank, but not on documentation-only commits.
 Releases should deploy on version tags (ex `/^[0-9]+\.[0-9]+\.[0-9]+/`), without consideration of if
 the commit is documentation only or not.
 
 * [configure_deploy] - Sets up environment and logs in, assuming [configure_test] was not called.
-* [deploy] - deploys the project, with arg0 being "master" or a release commit like "1.2.3"
+* [deploy] - deploys the project, with arg0 being "main" or a release commit like "1.2.3"
 
 ### Example GitHub Actions setup
 
@@ -91,8 +91,8 @@ conditions. The name `deploy.yml` and job `deploy` allows easy references to sta
 parity of the scripts it uses.
 
 The `on:` section obviates job creation and resource usage for irrelevant events. GitHub Actions
-cannot implement "master, except documentation only-commits" in the same file. Hence, deployments of
-master will happen even on README change.
+cannot implement "main, except documentation only-commits" in the same file. Hence, deployments of
+main will happen even on README change.
 
 Here's a partial `deploy.yml` including only the aspects mentioned above. Notice env variables are
 explicitly defined and `on.tags` is a [glob pattern](https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet).
@@ -101,7 +101,7 @@ explicitly defined and `on.tags` is a [glob pattern](https://docs.github.com/en/
 on:
   push:
     tags: '[0-9]+.[0-9]+.[0-9]+**'  # e.g. 8.272.10 or 15.0.1_p9
-    branches: master
+    branches: main
 
 jobs:
   deploy:
@@ -116,6 +116,6 @@ jobs:
           GH_USER: ${{ secrets.GH_USER }}
           GH_TOKEN: ${{ secrets.GH_TOKEN }}
       - name: Deploy
-        # GITHUB_REF will be refs/heads/master or refs/tags/1.2.3
+        # GITHUB_REF will be refs/heads/main or refs/tags/1.2.3
         run: build-bin/deploy $(echo ${GITHUB_REF} | cut -d/ -f 3)
 ```

build-bin/deploy

@@ -1,12 +1,12 @@
 #!/bin/sh -ue
 
-# This script deploys a master or release version.
+# This script deploys a main or release version.
 #
 # See [README.md] for an explanation of this and how CI should use it.
-version=${1:-master}
+version=${1:-main}
 
-# Use implicit version when master, if we can..
-if [ "${version}" = "master" ]; then
+# Use implicit version when main, if we can..
+if [ "${version}" = "main" ]; then
   version=$(sed -En 's/.*<version>(.*)<\/version>.*/\1/p' pom.xml| head -1)
 fi
 

build-bin/docker/docker_push

@@ -26,15 +26,15 @@
 set -ue
 
 docker_image=${1?docker_image is required, notably without a tag. Ex openzipkin/zipkin}
-version=${2:-master}
+version=${2:-main}
 
 # We don't need build kit, but Docker 20.10 no longer accepts --platform
 # without it. It is simpler to always enable it vs require maintainers to use
 # alternate OCI tools. See https://github.com/moby/moby/issues/41552
 export DOCKER_BUILDKIT=1
 
 case ${version} in
-  master )
+  main )
     is_release=false
     ;;
   *-SNAPSHOT )
@@ -55,7 +55,7 @@ if [ "${is_release}" = "true" ]; then
   fi
   docker_repos=${DOCKER_RELEASE_REPOS:-ghcr.io docker.io}
 else
-  docker_tags=master
+  docker_tags=main
   docker_repos=ghcr.io
 fi
 

build-bin/docker_push

@@ -1,7 +1,7 @@
 #!/bin/sh -ue
 
 # Pushes docker as part of `deploy` or from a trigger tag
-version=${1:-master}
+version=${1:-main}
 
 # handle trigger pattern like /^docker-[0-9]+\.[0-9]+\.[0-9]+$/
 case ${version} in

build-bin/maven/maven_build_or_unjar

@@ -29,8 +29,8 @@ classifier=${4:-}
 
 pom="${MAVEN_PROJECT_BASEDIR:-.}/pom.xml"
 
-# Use implicit version when master, if we can..
-if [ "${version}" = "master" ] && [ -f "${pom}" ]; then
+# Use implicit version when main, if we can..
+if [ "${version}" = "main" ] && [ -f "${pom}" ]; then
   version=$(sed -En 's/.*<version>(.*)<\/version>.*/\1/p' ${pom}| head -1)
 fi
 

build-bin/maven/maven_release

@@ -25,9 +25,9 @@ export MAVEN_OPTS="$($(dirname "$0")/maven_opts)"
 
 trigger_tag=${1?trigger_tag is required. Ex release-1.2.3}
 release_version=$(build-bin/git/version_from_trigger_tag release- ${trigger_tag})
-release_branch=${2:-master}
+release_branch=${2:-main}
 
-# Checkout master, as we release from master, not a tag ref
+# Checkout main, as we release from main, not a tag ref
 git fetch --no-tags --prune --depth=1 origin +refs/heads/${release_branch}:refs/remotes/origin/${release_branch}
 git checkout ${release_branch}
 

docker/Dockerfile

@@ -43,8 +43,8 @@ WORKDIR /install
 # /code contains what is allowed in .dockerignore. On problem, ensure .dockerignore is correct.
 ARG release_from_maven_build=false
 ENV RELEASE_FROM_MAVEN_BUILD=$release_from_maven_build
-# Version of the artifact to unjar. Ex. "2.4.5" or "2.4.5-SNAPSHOT" "master" to use the pom version.
-ARG version=master
+# Version of the artifact to unjar. Ex. "2.4.5" or "2.4.5-SNAPSHOT" "main" to use the pom version.
+ARG version=main
 ENV VERSION=$version
 ENV MAVEN_PROJECT_BASEDIR=/code
 RUN /code/build-bin/maven/maven_build_or_unjar io.zipkin.contrib.otel zipkin-module-otel ${VERSION} module

module/README.md

@@ -44,7 +44,7 @@ The Zipkin server can be further configured as described in the
 
 Configuration can be applied either through environment variables or an external Zipkin
 configuration file. The module includes default configuration that can be used as a
-[reference](https://github.com/openzipkin-contrib/zipkin-otel/tree/master/autoconfigure/collector/src/main/resources/zipkin-server-otel.yml)
+[reference](https://github.com/openzipkin-contrib/zipkin-otel/blob/main/module/src/main/resources/zipkin-server-otel.yml)
 for users that prefer a file based approach.
 
 | Property                             | Environment Variable          | Description                                              |