ci(dependabot): improve dependency auto merge

Only auto merge changes to GitHub Actions, and patch versions of Go
dependencies. Tests, and other CI checks, need to pass before any merge
can be performed, so if a patch dependency causes the build to fail we
won't end up with a broken binary.

.github/workflows/auto-merge.yaml

@@ -6,8 +6,25 @@ permissions:
   contents: write
   pull-requests: write
 jobs:
-  dependabot:
+  check-can-auto-merge:
     if: github.triggering_actor == 'dependabot[bot]'
+    name: Check if PR can be auto-merged
+    runs-on: ubuntu-latest
+    outputs:
+      can-auto-merge: ${{ steps.can-auto-merge.outputs.approve }}
+    steps:
+    - uses: dependabot/[email protected]
+      id: dependabot-metadata
+      with:
+        github-token: ${{ secrets.GITHUB_TOKEN }}
+    - if: |
+        steps.dependabot-metadata.outputs.update-type == 'version-update:semver-patch' ||
+        steps.dependabot-metadata.outputs.package-ecosystem == 'github_actions'
+      id: can-auto-merge
+      run: echo "approve=true" >> $GITHUB_OUTPUT
+  auto-merge:
+    needs: check-can-auto-merge
+    if: needs.check-can-auto-merge.outputs.can-auto-merge == 'true'
     name: Auto merge pull requests
     runs-on: ubuntu-latest
     steps:
@@ -19,11 +36,12 @@ jobs:
       run: gh pr review --approve "${PR_URL}"
       env:
         PR_URL: ${{ github.event.pull_request.html_url }}
+        # Because we enforce PRs be approved by a code owner, a token from the
+        # operations team must be used to approve the PR. This token is from the
+        # StatusCake machine account which has been given membership to the
+        # operations team.
         GITHUB_TOKEN: ${{ secrets.MACHINE_TOKEN }}
-    - if: |
-        steps.dependabot-metadata.outputs.update-type == 'version-update:semver-patch' ||
-        contains(github.event.pull_request.labels.*.name, 'github_actions')
-      name: Enable auto-merge for Dependabot PR
+    - name: Enable auto-merge for Dependabot PR
       run: gh pr merge --auto --merge "${PR_URL}"
       env:
         PR_URL: ${{ github.event.pull_request.html_url }}

CODE_OF_CONDUCT.md

@@ -5,30 +5,30 @@
 In the interest of fostering an open and welcoming environment, we as
 contributors and maintainers pledge to making participation in our project and
 our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, gender identity and expression, level of experience,
-nationality, personal appearance, race, religion, or sexual identity and
-orientation.
+size, disability, ethnicity, gender identity and expression, level of
+experience, nationality, personal appearance, race, religion, or sexual identity
+and orientation.
 
 ## Our Standards
 
 Examples of behaviour that contributes to creating a positive environment
 include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behaviour by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
-advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
   address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
+- Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
 ## Our Responsibilities
@@ -37,11 +37,11 @@ Project maintainers are responsible for clarifying the standards of acceptable
 behaviour and are expected to take appropriate and fair corrective action in
 response to any instances of unacceptable behaviour.
 
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviours that they deem inappropriate,
-threatening, offensive, or harmful.
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviours that they deem inappropriate, threatening,
+offensive, or harmful.
 
 ## Scope
 
@@ -55,20 +55,21 @@ further defined and clarified by project maintainers.
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behaviour may be
-reported by contacting the project team at [email protected]. All
+reported by contacting the [project team](mailto:[email protected]). All
 complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
+obligated to maintain confidentiality with regard to the reporter of an
+incident.  Further details of specific enforcement policies may be posted
+separately.
 
 Project maintainers who do not follow or enforce the Code of Conduct in good
 faith may face temporary or permanent repercussions as determined by other
 members of the project's leadership.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at [http://contributor-covenant.org/version/1/4][version]
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
 
 [homepage]: http://contributor-covenant.org
 [version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -8,6 +8,15 @@ If this application is found to be missing in functionality, please open an
 issue describing the proposed change - discussing changes ahead of time reduces
 friction within pull requests.
 
+## Prerequisites
+
+You will need the following things properly installed on your computer:
+
+- [Git](https://git-scm.com/)
+- [Go](https://go.dev/) (1.21+)
+- [Terraform](https://www.terraform.io/)
+- [Make](https://en.wikipedia.org/wiki/Make_(software)) (optional)
+
 ## Installation
 
 If you wish to work on the provider, you'll first need
@@ -20,17 +29,16 @@ To compile the provider, run `make build`. This will build the provider that
 should then be moved to the `$GOPATH/bin` directory.
 
 ```sh
-$ make build
-$ mv terraform-provider-statuscake $GOPATH/bin/terraform-provider-statuscake
-...
+make build
+mv terraform-provider-statuscake $GOPATH/bin/terraform-provider-statuscake
 ```
 
 To use the compiled binary the following must be included in the
 `~/.terraformrc` file, having replaced `FULL_PATH_TO_GO_BIN` with the full
 directory path to the `$GOPATH/bin` directory. This informs the Terraform CLI
 tool to lookup the binary in the `$GOPATH` instead of the regular location.
 
-```
+```terraformrc
 provider_installation {
   dev_overrides {
     "statuscakedev/statuscake" = "FULL_PATH_TO_GO_BIN"
@@ -39,40 +47,11 @@ provider_installation {
 }
 ```
 
-## Linting
-
-* `golint ./...`
-
 ## Running tests
 
-* `make testacc`
+- `make testacc`
 
 ## Making Changes
 
-Begin by creating a new branch. It is appreciated if branch names are written
-using kebab-case.
-
-```bash
-git checkout master
-git pull --rebase
-git checkout -b my-new-feature
-```
-
-Make the desired change, and ensure both the linter and test suite continue to
-pass. Once this requirement is met push the change back to a fork of this
-repository.
-
-```bash
-git push -u origin my-new-feature
-```
-
-Finally open a pull request through the GitHub UI. Upon doing this the CI suite
-will be run to ensure changes do not break current functionality.
-
-Changes are more likely to be approve if they:
-
-- Include tests for new functionality,
-- Are accompanied with a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html),
-- Contain few commits (preferably a single commit),
-- Do not contain merge commits,
-- Maintain backward compatibility.
+For additional contributing guidelines visit
+[devhandbook.org](https://devhandbook.org/contributing)

README.md

@@ -18,7 +18,7 @@
 
 ## Prerequisites
 
-You will need the following things properly installed on your computer.
+You will need the following things properly installed on your computer:
 
 - [Terraform](https://www.terraform.io/downloads.html) (1.0+)