Skip to content

Commit

Permalink
feat: automated releases and auto labelling
Browse files Browse the repository at this point in the history
Part of github/github-ospo#78

- [x] lint pr title adhering to conventional commits (helps with auto labelling)
  - [x] Update CONTRIBUTING.md
    - [x] automated releases
    - [x] how to file a bug report
    - [x] how to file an enhancement
  - [x] Update pull_request_template with new standard
- [x] setup autolabelling through release-drafter github action config
- [x] create auto-labeler workflow
- [x] change release-drafter workflow to release
  - [x] create release, including new tag
  - [x] create discussion announcement based on release
  - [x] build container images, tag them and release them

Manual Actions:

- [x] create `revert` and `maintenance` labels
- [x] put repository and category IDs into secrets for the discussion create action

Signed-off-by: jmeridth <jmeridth@gmail.com>
  • Loading branch information
jmeridth committed Apr 23, 2024
1 parent 9661c96 commit 389e804
Show file tree
Hide file tree
Showing 7 changed files with 197 additions and 60 deletions.
9 changes: 8 additions & 1 deletion .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,12 @@
# Pull Request
<!-- PR title should be brief and descriptive for a good changelog entry -->
<!--
PR title needs to be prefixed with a conventional commit type
(build,chore,ci,docs,feat,fix,perf,refactor,revert,style,test)
It should also be brief and descriptive for a good changelog entry
examples: "feat: add new logger" or "fix: remove unused imports"
-->

## Proposed Changes
<!-- Describe what the changes are and link to a GitHub Issue if one exists -->
Expand Down
37 changes: 32 additions & 5 deletions .github/release-drafter.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,9 @@ tag-template: 'v$RESOLVED_VERSION'
template: |
# Changelog
$CHANGES
See details of [all code changes](https://github.com/github/contributors/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION) since previous release
See details of [all code changes](https://github.com/github/contributors/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION) since previous release
categories:
- title: '🚀 Features'
labels:
Expand All @@ -23,6 +23,8 @@ categories:
- 'automation'
- 'documentation'
- 'dependencies'
- 'maintenance'
- 'revert'
- title: '🏎 Performance'
label: 'performance'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
Expand All @@ -35,7 +37,32 @@ version-resolver:
- 'enhancement'
patch:
labels:
- 'bug'
- 'maintenance'
- 'fix'
- 'documentation'
- 'maintenance'
default: patch
autolabeler:
- label: 'automation'
title:
- '/^(build|ci|perf|refactor|test).*/i'
- label: 'enhancement'
title:
- '/^(style).*/i'
- label: 'documentation'
title:
- '/^(docs).*/i'
- label: 'feature'
title:
- '/^(feat).*/i'
- label: 'fix'
title:
- '/^(fix).*/i'
- label: 'infrastructure'
title:
- '/^(infrastructure).*/i'
- label: 'maintenance'
title:
- '/^(chore|maintenance).*/i'
- label: 'revert'
title:
- '/^(revert).*/i'
28 changes: 28 additions & 0 deletions .github/workflows/auto-labeler.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
---
name: Auto Labeler

on:
# pull_request event is required only for autolabeler
pull_request:
# Only following types are handled by the action, but one can default to all as well
types: [opened, reopened, synchronize]
# pull_request_target event is required for autolabeler to support PRs from forks
pull_request_target:
types: [opened, reopened, synchronize]

permissions:
contents: read

jobs:
main:
permissions:
contents: write
pull-requests: write
name: Auto label pull requests
runs-on: ubuntu-latest
steps:
- uses: release-drafter/release-drafter@v6
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
config-name: release-drafter.yml
41 changes: 41 additions & 0 deletions .github/workflows/pr-title.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
## Reference: https://github.com/amannn/action-semantic-pull-request
---
name: "Lint PR Title"

on:
pull_request_target:
types:
- opened
- edited
- synchronize

permissions:
contents: read

jobs:
main:
permissions:
pull-requests: read
statuses: write
name: Validate PR title
runs-on: ubuntu-latest
steps:
- uses: amannn/action-semantic-pull-request@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
# Configure which types are allowed (newline-delimited).
# From: https://github.com/commitizen/conventional-commit-types/blob/master/index.json
# listing all below
types: |
build
chore
ci
docs
feat
fix
perf
refactor
revert
style
test
22 changes: 0 additions & 22 deletions .github/workflows/release-drafter.yml

This file was deleted.

82 changes: 82 additions & 0 deletions .github/workflows/release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
---
name: Release

on:
workflow_dispatch:
push:
branches:
- main

permissions:
contents: read

jobs:
create_release:
outputs:
full-tag: ${{ steps.release-drafter.outputs.tag_name }}
short-tag: ${{ steps.get_tag_name.outputs.SHORT_TAG }}
body: ${{ steps.release-drafter.outputs.body }}
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: read
steps:
- uses: release-drafter/release-drafter@v6
id: release-drafter
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
config-name: release-drafter.yml
publish: true
- name: Get the short tag
id: get_tag_name
run: |
short_tag=$(echo ${{ steps.release-drafter.outputs.tag_name }} | cut -d. -f1)
echo "SHORT_TAG=$short_tag" >> $GITHUB_OUTPUT
create_action_images:
needs: create_release
runs-on: ubuntu-latest
permissions:
packages: write
env:
REGISTRY: ghcr.io
IMAGE_NAME: ${{ github.repository }}
steps:
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Log in to the Container registry
uses: docker/login-action@v3
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: actions/checkout@v4
- name: Push Docker Image
if: ${{ success() }}
uses: docker/build-push-action@v5
with:
context: .
file: ./Dockerfile
push: true
tags: |
${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ needs.create_release.outputs.full-tag }}
${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ needs.create_release.outputs.short-tag }}
platforms: linux/amd64
provenance: false
sbom: false
create_discussion:
needs: create_release
runs-on: ubuntu-latest
permissions:
discussions: write
steps:
- name: Create an announcement discussion for release
uses: abirismyname/create-discussion@v1.2.0
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
title: ${{ needs.create_release.outputs.full-tag }}
body: ${{ needs.create_release.outputs.body }}
repository-id: ${{ secrets.RELEASE_DISCUSSION_REPOSITORY_ID }}
category-id: ${{ secrets.RELEASE_DISCUSSION_CATEGORY_ID }}
38 changes: 6 additions & 32 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,18 +53,7 @@ A good bug report shouldn't leave others needing to chase you up for more inform
<!-- omit in toc -->
### How Do I Submit a Good Bug Report?

We use GitHub issues to track bugs and errors. If you run into an issue with the project:

- Open an [Issue](https://github.com/github/contributors/issues/new). (Since we can't be sure at this point whether it is a bug or not, we ask you not to talk about a bug yet and not to label the issue.)
- Explain the behavior you would expect and the actual behavior.
- Please provide as much context as possible and describe the *reproduction steps* that someone else can follow to recreate the issue on their own. This usually includes your code. For good bug reports you should isolate the problem and create a reduced test case.
- Provide the information you collected in the previous section.

Once it's filed:

- The project team will label the issue accordingly.
- A team member will try to reproduce the issue with your provided steps. If there are no reproduction steps or no obvious way to reproduce the issue, the team will ask you for those steps and mark the issue as `needs-repro`. Bugs with the `needs-repro` tag will not be addressed until they are reproduced.
- If the team is able to reproduce the issue, it will be marked `needs-fix`, as well as possibly other tags (such as `critical`), and the issue will be left to be implemented by someone.
Please submit a bug report using our [GitHub Issues template](https://github.com/github/stale-repos/issues/new?template=bug_report.yml).

## Suggesting Enhancements

Expand All @@ -81,27 +70,12 @@ This section guides you through submitting an enhancement suggestion for contrib
<!-- omit in toc -->
### How Do I Submit a Good Enhancement Suggestion?

Enhancement suggestions are tracked as [GitHub issues](https://github.com/github/contributors/issues).
Please submit an enhancement suggestion using our [GitHub Issues template](https://github.com/github/stale-repos/issues/new?template=feature_request.yml).

### Pull Request Standards

- Use a **clear and descriptive title** for the issue to identify the suggestion.
- Provide a **step-by-step description of the suggested enhancement** in as many details as possible.
- **Describe the current behavior** and **explain which behavior you expected to see instead** and why. At this point you can also tell which alternatives do not work for you.
- You may want to **include screenshots and animated GIFs** which help you demonstrate the steps or point out the part which the suggestion is related to.
- **Explain why this enhancement would be useful** to most contributors users.
We are using [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) to standardize our pull request titles. This allows us to automatically generate labels and changelogs and follow semantic versioning. Please follow the commit message format when creating a pull request. What pull request title prefixes are expected are in the [pull_request_template.md](.github/pull_request_template.md) that is shown when creating a pull request.

## Releases

To release a new version, maintainers are to release new versions following semantic versioning and via GitHub Releases.
Once the code is ready to release please do the following

1. Create a [GitHub release](https://github.com/github/contributors/releases) based off the current draft and review release notes
2. Ensure that the versioning is correct given the content of the release
3. Check the box to release it to the GitHub Marketplace
4. Publish the release
5. Clone the repository at the release tag locally or in a codespace
6. Authenticate to ghcr.io using [these instructions](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-to-the-container-registry)
7. `docker build -t ghcr.io/github/contributors:v1 .` where v1 is the current major version number
8. `docker build -t ghcr.io/github/contributors:v1.0.0 .` where v1.0.0 is the full version number
9. `docker push ghcr.io/github/contributors:v1` where v1 is the current major version number
10. `docker push ghcr.io/github/contributors:v1.0.0` where v1.0.0 is the full version number
11. Update the `action.yml` and `README.md` instructions to point to the new docker container if its a major version number change
Releases are automated but if you need to manually initiate a release you can do so through the GitHub Actions UI. If you have permissions to do so, you can navigate to the [Actions tab](https://github.com/github/stale-repos/actions/workflows/release.yml) and select the `Run workflow` button. This will allow you to select the branch to release from and the version to release.

0 comments on commit 389e804

Please sign in to comment.