Update release process to use actions (#392)

* Update release process to use actions

* Add publish pubdev and some minor cleanup

.github/workflows/create_release.yml

@@ -0,0 +1,16 @@
+name: Create Release
+on:
+  push:
+    tags:
+      - '*'
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v3
+    - name: Create a Release
+      uses: elgohr/Github-Release-Action@v5
+      env:
+        GITHUB_TOKEN: "${{ secrets.RELEASE_TOKEN }}"
+      with:
+        title: ${{ github.ref }}

.github/workflows/create_tag.yml

@@ -0,0 +1,25 @@
+name: Release
+
+# Runs when a PR merges.
+# See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-workflow-when-a-pull-request-merges
+on:
+  pull_request:
+    types:
+      - closed
+
+jobs:
+  release:
+    if: github.event.pull_request.merged == true
+    runs-on: ubuntu-latest
+    container: dart
+    permissions:
+      contents: write
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          ref: master
+      - uses: jacopocarlini/[email protected]
+        with:
+          GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

.github/workflows/publish_pubdev.yml

@@ -0,0 +1,14 @@
+# .github/workflows/publish.yml
+name: Publish to pub.dev
+
+on:
+  push:
+    tags:
+    - '[0-9]+.[0-9]+.[0-9]+*'
+
+# Publish using the reusable workflow from dart-lang.
+jobs:
+  publish:
+    permissions:
+      id-token: write # Required for authentication using OIDC
+    uses: dart-lang/setup-dart/.github/workflows/publish.yml@v1

CONTRIBUTING.md

@@ -15,7 +15,7 @@ GitHub.dart is of course Open Source! We love it when people contribute!
 - [Commit your code](http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository) for each logical change (see [tips for creating better commit messages](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message)).
 - [Push your change](https://help.github.com/articles/pushing-to-a-remote) to your fork.
 - [Create a Pull Request](https://help.github.com/articles/creating-a-pull-request) on GitHub for your change.
-- Wait for reviewers (usually kaendfinger) to give feedback.
+- Wait for reviewers (usually robrbecker) to give feedback.
 - When the reviewers think that the Pull Request is ready, they will merge it.
 
 ## Code Style
@@ -34,12 +34,14 @@ Pull Request rejections are not a bad thing. It just means you need to fix somet
 
 To regenerate the JSON logic for the models, run:
 
-```
+```sh
 dart run build_runner build -d
 ```
 
 ## Tests
 
+`dart test` will only run the unit tests.
+
 To run the complete test suite you will need to install
 `octokit/fixtures-server`.
 
@@ -52,29 +54,12 @@ GitHub and execute tests against it using your localhost port 3000.
 
 ## Contacting Us
 
-- IRC: `#directcode on irc.esper.net and irc.freenode.net`
-- Email: `[email protected]`
-
-## Becoming a Committer
-
-If you get on IRC and ask us, we can review your work and add you as a committer if we think you should have it.
-
-## Releasing & Publishing
-
-This repo is now configured to release after every PR merge. This means a couple of things for PRs that are put up:
+File issues at https://github.com/SpinlockLabs/github.dart/issues
 
-1. A semver label is required. A GitHub check will remind you that you need one. Reviewers should check that it is correct. See https://semver.org/ to understand more.
-2. There is no need to modify the version in the pubspec.yaml in your PRs. The tooling will update the version according to the semver label applied to your PR.
-3. Same thing for the CHANGELOG.md. Tooling will update it automatically after merge.
-4. A GitHub release will be created and published to pub.dev for you.
+## Releases
 
-For example if your PR has `semver:minor` label applied and the latest version is 1.2.3, once merged, the tooling will:
-- update the pubspec.yaml to 1.3.0
-- Add the GitHub auto-generated release notes with 1.3.0 to the top of the CHANGELOG.md
-- Create a release in GitHub for 1.3.0 (which creates a git tag of 1.3.0)
-- Remove the `unreleased` label from the PR and add the `released` label
-- Comment on the PR stating the version that it was released in and link to the release
-- When the release is created, it will automatically be published to pub.dev
+Merged pull requests that edit the `pubspec.yaml` version will create new releases.
+Once CI is green, it will create a tag for that commit based on the version, which
+gets published by pub.dev.
 
-NOTE: If you want the ability to merge a PR **WITHOUT** automatically releasing and publishing, simply add the `no_release_on_merge` label before merging. Do note that the PR has been merged though and whatever the next PR is that triggers a release will release and publish everything that has been merged. So if you want to batch a few PRs into 1 release, label them all `no_release_on_merge`. Then whichever is the last to be merged, remove that label before merging to trigger the release.
-You may also manually trigger the action to release unreleased PRs from the Actions tab in GitHub.
+If no new version was created, nothing will be published.