Skip to content

Commit

Permalink
ci: use GitHub token (#904)
Browse files Browse the repository at this point in the history
Co-authored-by: Arpit Gaur <arpitgaur@microsoft.com>
Co-authored-by: Ross Smith <ross-p-smith@users.noreply.github.com>
  • Loading branch information
3 people authored May 17, 2024
1 parent 21064e7 commit 0dedf7f
Show file tree
Hide file tree
Showing 7 changed files with 68 additions and 49 deletions.
15 changes: 15 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,21 @@
- [ ] Yes
- [ ] No

<!-- Please prefix your PR title with one of the following:
* `feat`: A new feature
* `fix`: A bug fix
* `docs`: Documentation only changes
* `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
* `refactor`: A code change that neither fixes a bug nor adds a feature
* `perf`: A code change that improves performance
* `test`: Adding missing tests or correcting existing tests
* `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
* `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
* `chore`: Other changes that don't modify src or test files
* `revert`: Reverts a previous commit
* !: A breaking change is indicated with a `!` after the listed prefixes above, e.g. `feat!`, `fix!`, `refactor!`, etc.
-->

## How to Test
* Get the code

Expand Down
41 changes: 41 additions & 0 deletions .github/workflows/create-release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
on:
workflow_run:
workflows: ["CI"]
types:
- completed

permissions:
contents: write

name: create-release

jobs:
create-release:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}

steps:
- name: Checkout
uses: actions/checkout@v4

- name: Conventional Changelog Action
id: changelog
uses: TriPSs/conventional-changelog-action@v5
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
output-file: 'CHANGELOG.md'
git-user-name: 'github-actions[bot]'
git-user-email: 'github-actions[bot]@users.noreply.github.com'
version-file: './pyproject.toml'
version-path: 'tool.poetry.version'


- name: Create Release
uses: actions/create-release@v1
if: ${{ steps.changelog.outputs.skipped == 'false' }}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ steps.changelog.outputs.tag }}
release_name: ${{ steps.changelog.outputs.tag }}
body: ${{ steps.changelog.outputs.clean_changelog }}
23 changes: 0 additions & 23 deletions .github/workflows/release-please.yml

This file was deleted.

31 changes: 9 additions & 22 deletions docs/RELEASE_GUIDELINES.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,42 +12,29 @@ This repository uses GitHub's in-built [Releases](https://docs.github.com/en/rep

# Automated releases

In order to automate the generation of a changelog, the creation of a release, and the bumping of a version number, we use [Release Please](https://github.com/googleapis/release-please).
In order to automate the generation of a changelog, the creation of a release, and the bumping of a version number, we use the [Conventional Changelog Action](https://github.com/TriPSs/conventional-changelog-action).

It works by inferring from the commit history what changes have been made, and hence what version should be assigned. This is why it is important for Pull Request titles to adhere to the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification, which many repositories use. This convention uses types such as `docs`, `fix`, `feat`, etc to label commits and PRs.

From these, the [semantic version](https://semver.org/) of a release can be identified. For example a release which consists of a PR which adds a feature (`feat`) would result in an increment of the Minor part of the semantic version, e.g. 1.1.0 -> 1.2.0.

Using Release Please takes much of the manual work out of creating a release, requiring only an approval from a maintainer to approve the release.
Using the Conventional Changelog Action along with GitHub Releases takes all of the manual work out of creating a release.

# Release Please Action
# Conventional Changelog Action

## Usage

We use the [Release Please](https://github.com/google-github-actions/release-please-action) GitHub Action, which you can find in `./github/workflows/release-please.yml`.
We use the [Conventional Changelog](https://github.com/TriPSs/conventional-changelog-action) GitHub Action, which you can find in `./github/workflows/create-release.yml`.

Once a PR is merged, the Action will automatically run and update a Release PR. It will automatically create the changelog and version number of the release. If subsequent PRs are merged, the Release PR will update to reflect these new changes. Once ready, the release PR can be merged and the main page of the repository will be updated with the new release.
Once a PR is merged to `main`, the Action will automatically run. It will automatically generate a changelog, and if that changelog is empty, then no release is made. This would be the case for merges to `main` that include `docs`, `chore`, etc.

## Security

Due to the restrictions on this repository, and the inability to enable Actions to create pull requests, this workflow uses a personal access token.
Once a merge to `main` is completed that would result in a major/minor/patch version increase (such as `feat`, `fix`, etc.) then a changelog will be generated, and this will trigger a release to be published automatically with the appropriate version number.

You can generate a personal access token by going to your [profile](https://github.com/settings/profile) > Developer settings > Personal access tokens.
The workflow is configured so that the `CHANGELOG.md` is continuously updated. The Action by default uses the `package.json` version, which it also automatically updates.

- Token name: `RELEASE_PLEASE_TOKEN`
- Expiration: `90 days`
- Resource Owner: `Azure-Samples`
- Repository access: `Only select repositories` > `chat-with-your-data-solution-accelerator`

The personal access token must be regenerated every 90 days. It must have the following permissions in order for the GitHub Action to be able to create a release pull request:
- Actions: `Read and write`
- Contents: `Read and write`
- Merge queues: `Read and write`
- Metadata: `Read-only`
- Pull requests: `Read and write`
- Workflows: `Read and write`
## Security

Once the personal access token has been generated, it should be stored in the repository Settings, under Security > Secrets and Variables > Actions > RELEASE_PLEASE_TOKEN.
The GitHub Action to create the release requires only the GitHub token, as this has sufficient permissions for it to checkout main (and read the commit history) and to create a release for the repository.

# Conventional Commits

Expand Down
4 changes: 2 additions & 2 deletions docs/design/adrs/2024-05-02-enable-project-versioning.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,6 @@ Pros:
- When introducing automated versioning, there are a few things we need to consider:
- **major/minor/patch** versions: Each release is tagged with a semantic version which is based on the change included (e.g. breaking change, feature, bug fix).
- **Changelog**: A changelog must be included which details the changes that are included in the release.
- The [**release-please**](https://github.com/google-github-actions/release-please-action) GitHub Action is created by Google, and automates releases. It looks at commit messages to automatically generate the version number and to generate the changelog.
- The [**conventional-changelog-action**](https://github.com/TriPSs/conventional-changelog-action) GitHub Action automates releases. It looks at commit messages to automatically generate the version number and to generate the changelog.
- It uses [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), meaning we'd need to follow a convention of labelling PRs with `fix`/`feat`/`BREAKING CHANGE`, etc, in order to be picked up by the release generator. It uses these labels to create the correct version.
- As a consequence, current dependabot PRs would not trigger a release PR. These would be in main until a automatic or manual release was triggered.
- As a consequence, current dependabot PRs would not trigger a release PR. These would be in main until an automatic or manual release was triggered.
2 changes: 1 addition & 1 deletion pyproject.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[tool.poetry]
name = "chat-with-your-data-solution-accelerator"
version = "0.1.0"
version = "1.1.0"
description = "Chat with your data solution accelerator"
authors = []
readme = "README.md"
Expand Down
1 change: 0 additions & 1 deletion version.txt

This file was deleted.

0 comments on commit 0dedf7f

Please sign in to comment.