Skip to content

Commit

Permalink
Update the RELEASE.md file with the latest instructions (#2239)
Browse files Browse the repository at this point in the history 
* Update the RELEASE.md file with the latest instructions

* Update docs/DEVELOPMENT.md

Co-authored-by: Andrea Lamparelli <a.lamparelli95@gmail.com>

* Update docs/RELEASE.md

Co-authored-by: Andrea Lamparelli <a.lamparelli95@gmail.com>

---------

Co-authored-by: Andrea Lamparelli <a.lamparelli95@gmail.com>
  • Loading branch information
@diegolovison @lampajr
diegolovison and lampajr authored Jan 15, 2025
1 parent 7f72432 commit d6087c2
Show file tree
Hide file tree
Showing 2 changed files with 27 additions and 142 deletions.
10 changes: 10 additions & 0 deletions docs/DEVELOPMENT.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -203,3 +203,13 @@ 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` (or `backport-squash`) label to the original PR and a new PR will be automatically generated. You will then need to review and merge the backport PR.

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.
159 changes: 17 additions & 142 deletions docs/RELEASE.md
View file
Original file line number Diff line number Diff line change
@@ -1,151 +1,26 @@
# Release
# Release Horreum

## Building a base image
## Creating a new stable branch
This step is not required if you are going to perform a micro release from an already existing stable branch, e.g., `0.17.5`.

You can build a base image for the Horreum distribution with
Open https://github.com/Hyperfoil/Horreum/actions/workflows/branch.yml and run the workflow. Select the `master` branch.

```bash
cd horreum-backend/
docker build -f src/main/docker/Dockerfile.jvm.base -t quay.io/hyperfoil/horreum-base:latest .
```
## Perform Release

Then it can be pushed to [quay.io](https://quay.io/) with
Open https://github.com/Hyperfoil/Horreum/actions/workflows/release.yml and run the workflow. Select the previous branch created.

```bash
docker push quay.io/hyperfoil/horreum-base:latest
```
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)

if the proper credentials are in place.
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.

## quay.io and docker
# Release Horreum clients

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

0 comments on commit d6087c2

Please sign in to comment.