Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the RELEASE.md file with the latest instructions #2239

Merged
merged 3 commits into from
Jan 15, 2025
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions docs/DEVELOPMENT.md
Original file line number Diff line number Diff line change
Expand Up @@ -203,3 +203,6 @@ quarkus.liquibase.migration.validate-on-migrate=false
quarkus.datasource.migration.username=<migration-user-name>
quarkus.datasource.migration.password=<migration-user-password>
```

# Backports
When developing new features, we always create pull requests (PRs) in the `master` branch. However, we always support the latest stable branch. If you encounter an issue that requires a fix for the stable branch, you can add the `backport` label to the original PR and a new PR will be automatically generated. You will then need to review and merge the backport PR.
diegolovison marked this conversation as resolved.
Show resolved Hide resolved
159 changes: 16 additions & 143 deletions docs/RELEASE.md
Original file line number Diff line number Diff line change
@@ -1,151 +1,24 @@
# Release
# Release Horreum

## Building a base image
## Creating a new stable branch
Open https://github.com/Hyperfoil/Horreum/actions/workflows/branch.yml and run the workflow. Select the `master` branch.

diegolovison marked this conversation as resolved.
Show resolved Hide resolved
You can build a base image for the Horreum distribution with
## Perform Release

```bash
cd horreum-backend/
docker build -f src/main/docker/Dockerfile.jvm.base -t quay.io/hyperfoil/horreum-base:latest .
```
Open https://github.com/Hyperfoil/Horreum/actions/workflows/release.yml and run the workflow. Select the previous branch created.

Then it can be pushed to [quay.io](https://quay.io/) with
This workflow will take care of releasing all artifacts and container images on the appropriate registries:
* Create a new GitHub tag following the semantic versioning (e.g., 0.17.0-SNAPSHOT → 0.17.0)
* Push the maven artifacts to [Sonatype](https://s01.oss.sonatype.org/#nexus-search;quick~horreum)
* Push the generated container image to [quay.io/hyperfoil/horreum](https://quay.io/repository/hyperfoil/horreum)

```bash
docker push quay.io/hyperfoil/horreum-base:latest
```
The only missing step is the creation of the GitHub release, a step that at the moment needs to be done manually using the GitHub UI. Consider using the “Generate release notes” feature to pre-populate the release notes automatically after selecting the correct tags.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“Generate release notes” works well for point releases, but not for the first 0.x.0 release, the first time a new stable branch is released. This is due to us backporting commits to the previous stable branch, where features/fixes will have been backported to the 0.x-1.0 branch with a different commit hash.

We have not thought about how we can improve this, and atm for the first release from a new branch, we also have to manually remove the commits that had been backported from the release notes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, unfortunately this seems a drawback of releasing from a stable branch where we cherry-pick commits (that, as you already highlighted, have different SHAs).

Not sure whether we should add this clarification in the RELEASE.md doc 🫤

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO, we should add what was mentioned. @johnaohara would you like to open a PR?

if the proper credentials are in place.
# Release Horreum clients

## quay.io and docker

Login to [quay.io](https://quay.io/) using [docker](https://docker.io/)

```bash
docker login quay.io
```

Logout of [quay.io](https://quay.io/) using [docker](https://docker.io/)

```bash
docker logout quay.io
```

## Backports

Backports are automatically created from PRs against the master branch to the stable branch.

To backport a change, add the `backport` (or `backport-squash` but not both) label to the PR that you opened against the master branch.

Which label should I use?
* `backport`: (default) this uses the `no-squash=true` option so that the tool tries to backport all commits coming
from the original pull request you are trying to backport.
> _**Note**_ that in this case the commit SHAs should exist during the backporting, i.e,
delete the source branch only after the backporting PR got created.
* `backport-squash`: with this label you set `no-squash=false` option, so that the tool tries to backport the pull request
`merge_commit_sha`.
> _**Note**_ the value of the `merge_commit_sha` attribute changes depending on the state of the pull request, see [Github doc](https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#get-a-pull-request)
for more details.

After the PR is merged, the backport PR will be automatically created.

Backport PRs will be tested by the CI and need to be merged manually.

## Building a release

Make sure that the [nodejs](https://nodejs.org/en) installation is clean,

```bash
mvn -Premove-node-cache clean
git checkout horreum-web/package-lock.json
```

Then run the [Maven](https://maven.apache.org/) release procedure

```bash
CI=true mvn -DskipTests clean javadoc:javadoc install
CI=true mvn -Darguments=-DskipTests release:prepare
CI=true mvn -Darguments=-DskipTests release:perform
```

Now we can build the tag

```bash
git checkout <tag>
CI=true mvn -DskipTests -DskipITs clean install
```

and find the image using

```bash
docker images
```

and tag it to the release

```bash
docker tag quay.io/hyperfoil/horreum:<tag> quay.io/hyperfoil/horreum:<release>
docker tag quay.io/hyperfoil/horreum:<release> quay.io/hyperfoil/horreum:latest
```

and finally push them

```bash
docker push quay.io/hyperfoil/horreum:<release>
docker push quay.io/hyperfoil/horreum:latest
```

Generate release notes:

https://github.com/Hyperfoil/Horreum/releases

## Creating a new Stable Branch

To create a new stable branch, for example creating a `0.11.x` branch, first create the branch locally:

```bash
git checkout origin/master
git branch 0.11.x master
```

Update the new main branch to the next snapshot version:

```bash
mvn versions:set -DnewVersion=0.12-SNAPSHOT
mvn versions:set-property -Dproperty=major-version -DnewVersion=0.12
```

Update the Github actions to build the new stable branch for each push:

```yaml
on:
push:
branches: [ master, 0.11.x ]
tags: [ "*" ]
pull_request:
workflow_dispatch:
```

Update the Github action to notify openapi changes to the clients on every stable branch push:
```yaml
on:
push:
branches: [ master, 0.11.x ]
paths:
- "docs/site/content/en/openapi/openapi.yaml"
```

Commit the changes:

```bash
git add .
git commit -m "Next is 0.12"
```

Push the new branch and main branch to github:

```bash
git push origin 0.11.x
git push origin master
```
After testing the new release or release candidate, a new version of each client must be created by following the `RELEASE.md` document in each repository

* https://github.com/Hyperfoil/horreum-client-golang
* * https://github.com/Hyperfoil/horreum-client-golang/blob/main/docs/RELEASE.md
* https://github.com/Hyperfoil/horreum-client-python
* * https://github.com/Hyperfoil/horreum-client-python/blob/main/docs/RELEASE.md
Loading