maint: Create Github release as part of release workflow (#53)

## Which problem is this PR solving?

Creates a Github release as part of the release workflow.

- Closes #36 

## Short description of the changes

- Adds a release step to `.github/workflows/release.yaml` that creates a
prerelease, draft Github release using
[softprops/action-gh-release@v1](https://github.com/softprops/action-gh-release)
- Adds a `.github/release.yaml` that automatically formats the release
body with changes based on labeled PRs
- Update `CHANGELOG.md` with previous two tags
- Update `RELEASING.md` with notes on releasing process

## How to verify that this has the expected result

The next pushed tag results in a release !

---------

Co-authored-by: JamieDanielson <jamieedanielson@gmail.com>

.github/release.yaml

@@ -0,0 +1,23 @@
+# .github/release.yml
+
+changelog:
+  exclude:
+    labels:
+      - no-changelog
+  categories:
+    - title: 💥 Breaking Changes 💥
+      labels:
+        - "version: bump major"
+        - breaking-change
+    - title: 💡 Enhancements
+      labels:
+        - "type: enhancement"
+    - title: 🐛 Fixes
+      labels:
+        - "type: bug"
+    - title: 🛠 Maintenance
+      labels:
+        - "type: maintenance"
+    - title: 🤷 Other Changes
+      labels:
+        - "*"

.github/workflows/release.yaml

@@ -42,3 +42,9 @@ jobs:
           platforms: linux/amd64,linux/arm64
           cache-from: type=gha
           cache-to: type=gha,mode=max
+
+      - name: Release
+        uses: softprops/action-gh-release@v1
+        with:
+          prerelease: true
+          draft: true

CHANGELOG.md

@@ -1,2 +1,15 @@
 # Honeycomb eBPF Agent changelog
 
+## [0.0.2] - 2023-07-27
+
+### Enhancements
+
+- feat: map IP address to pod name (#42) | @pkanal
+
+### Maintenance
+
+- maint: add developing notes and comments (#41) | @JamieDanielson
+
+## [0.0.1] - 2023-07-18
+
+Initial release

RELEASING.md

@@ -1,11 +1,13 @@
 # Releasing
 
-- `Add steps to prepare release`
-- Update `CHANGELOG.md` with the changes since the last release.
+- Update version number in `main.go`
+- Update `CHANGELOG.md` with the changes since the last release. Consider automating with a command such as these two:
+  - `git log $(git describe --tags --abbrev=0)..HEAD --no-merges --oneline > new-in-this-release.log`
+  - `git log --pretty='%C(green)%d%Creset- %s | [%an](https://github.com/)'`
 - Commit changes, push, and open a release preparation pull request for review.
 - Once the pull request is merged, fetch the updated `main` branch.
-- Apply a tag for the new version on the merged commit (e.g. `git tag -a v1.2.3 -m "v1.2.3"`)
-- Push the tag upstream (this will kick off the release pipeline in CI) e.g. `git push origin v1.2.3`
-- Copy change log entry for newest version into draft GitHub release created as part of CI publish steps.
-  - Make sure to "generate release notes" in github for full changelog notes and any new contributors
-- Publish the github draft release and this will kick off publishing to GitHub and the NPM registry.
+- Apply a tag for the new version on the merged commit (e.g. `git tag -a v0.1.0-alpha -m "v0.1.0-alpha"`)
+- Push the tag upstream (this will kick off the release pipeline in CI) e.g. `git push origin v0.1.0-alpha`
+- Ensure that there is a draft GitHub release created as part of CI publish steps.
+- Click "generate release notes" in GitHub for full changelog notes and any new contributors
+- Publish the GitHub draft release - if it is a prerelease (e.g. beta) click the prerelease checkbox.