feat: dockerize repository and release package on ghcr.io

[0-vortex]

What type of PR is this? (check all applicable)

• ♻️ Refactor
• ✨ Feature
• 🐛 Bug Fix
• 👷 Optimization
• 📝 Documentation Update
• 🔖 Release
• 🚩 Other

Description

This PR:

• adds the ability to run our semantic-release configuration from a docker container
• adds the ability to run our semantic-release configuration from a GitHub action
• enables usage of our release tooling and configuration without installing any more dependencies
• simplifies the release workflow by removing almost all environment variables
• configuration is now aware of existing Dockerfile and action.yml configuration
• fixes the [skip ci] bug in alpha and beta pre-release branches
• fixes the npm ci build-cache using Bahmutov action
• adds better usage documentation and examples
• adds license update function and git asset configuration
• adds better changelog generation

Related Tickets & Documents

closes #11
closes #18
closes #24

Mobile & Desktop Screenshots/Recordings

Added tests?

• 👍 yes
• 🙅 no, because they aren't needed
• 🙋 no, because I need help

Added to documentation?

• 📜 readme
• 📜 contributing.md
• 📓 docs
• 📕 storybook
• 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?

• update maintainer docs
• write a dev.to blog post
• convince @mtfoley this action was designed for them

[optional] What gif best describes this PR or how it makes you feel?

[0-vortex]

@bdougie @mtfoley mind me pinging but you really need to see this, working on the docs right now but there are a lot of gaps due to rapid development, could really use your input!

[mtfoley]

So I read that in the original issue #18 that the purpose behind doing this is creating docker images so contributors don't need to deal with dependencies directly. How would this change the workflow of cases where a contributor is adding dependencies to the project for features?

[0-vortex]

So I read that in the original issue #18 that the purpose behind doing this is creating docker images so contributors don't need to deal with dependencies directly. How would this change the workflow of cases where a contributor is adding dependencies to the project for features?

Other workflows would handle this - for now what this means is that with the simple squash flow enabled by your action we can simplify almost all releases with this workflow:

name: "Release"

on:
  push:
    branches:
      - main

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: "🚀 release"
        id: semantic-release
        uses: docker://ghcr.io/open-sauced/semantic-release-conventional-config:3.18.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: 'test'
        run: |
          echo ${{ env.RELEASE_TAG }}
          echo ${{ env.RELEASE_VERSION }}

No more local dependencies, commit convention handled by your action, BOOM 🍕

[0-vortex]

The bug fixes and general semantic-release quirks can be seen in open-sauced-semantic-config-test and the performance improvements from running the release process in semantic-release-docker-test - both repositories I have created to be less spammy on open-sauced.

We really need alpha and beta branches enabled and documented, feel like they are so much easier to work with in the long run :D

[0-vortex]

Linking this back to discussion#1319, is it worth doing this now, re-releasing at a later stage?

PS: It's ready for release except the pre-release branches!

[github-actions]

🎉 This PR is included in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release
• ghcr.io container (@latest dist-tag)

Your semantic-release bot 📦🚀