Skip to content

Commit

Permalink
Updated the release checklist (#135)
Browse files Browse the repository at this point in the history
* Updated release checklist

* Updated release script to also push the latest tag

* Also updated development guide
  • Loading branch information
ilyakooo0 authored Oct 11, 2021
1 parent 9a65f19 commit 43d6f53
Show file tree
Hide file tree
Showing 4 changed files with 18 additions and 31 deletions.
9 changes: 8 additions & 1 deletion .github/workflows/build.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -117,13 +117,20 @@ jobs:
uses: ./.github/actions/common_setup
with:
cachixSigningKey: ${{ secrets.CACHIX_SIGNING_KEY }}
- name: Push Docker Images to DockerHub
- name: Push Docker Release Images to DockerHub
uses: ./.github/actions/push_docker_images
with:
tag: ${{ github.event.inputs.version }}
docker_username: ${{ secrets.DOCKERHUB_USERNAME }}
docker_password: ${{ secrets.DOCKERHUB_TOKEN }}

- name: Push Docker latest Images to DockerHub
uses: ./.github/actions/push_docker_images
with:
tag: latest
docker_username: ${{ secrets.DOCKERHUB_USERNAME }}
docker_password: ${{ secrets.DOCKERHUB_TOKEN }}

- uses: actions/download-artifact@v2
- name: Zip and move
run: |
Expand Down
17 changes: 5 additions & 12 deletions Development_guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,14 +2,7 @@

## Git flow

`master` contains the latest "release version" only.

All development should be done in the `develop` branch.

Feature PRs are created to the `develop` branch and merged with all commits **squashed**. This leads to us having every commit in the `develop` branch corresponds to exactly one feature or bug fix.

When a release is ready, the `develop` branch is merged into the `master` branch using **rebase and merge**. This makes the `master` branch have every commit be a feature or bug fix. Merging to master triggers a CI script that collects all commits since the last merge and creates a new release with a change log of all commits.

Feature branches are merged into `master`. There is no `develop` branch.
## Building

### Nix Installation
Expand All @@ -22,13 +15,13 @@ curl https://nixos.org/nix/install | sh

### Nix cache

#### Reflex platform cache
#### Haskell.nix cache

To speedup initial project builds you will want to set up the Reflex Platform binary nix cache – append the following to `/etc/nix/nix.conf`:
To speedup initial project builds you will want to set up the haskell.nix binary nix cache – append the following to `/etc/nix/nix.conf`:

```
binary-caches = https://cache.nixos.org https://nixcache.reflex-frp.org
binary-cache-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= ryantrinkle.com-1:JJiAKaRv9mWgpVAz8dwewnZe0AzzEAzPkagE9SP5NWI=
binary-caches = https://hydra.iohk.io https://cache.nixos.org/
binary-cache-public-keys = hydra.iohk.io:f/Ea+s+dFdN+3Y/G+FDgSq+a5NEWhJGzdjvKNGv0/EQ= cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=com-1:JJiAKaRv9mWgpVAz8dwewnZe0AzzEAzPkagE9SP5NWI=
binary-caches-parallel-connections = 40
```

Expand Down
23 changes: 5 additions & 18 deletions Release_checklist.md
Original file line number Diff line number Diff line change
@@ -1,21 +1,8 @@
# Release checklist

1. Update the referenced tags in the documentation
2. If there were changes to the examples:
1. Build and push the new containers:
1. octopod-web-app-example
2. octopod-helm-example
2. Create a new tag incrementing the integer version number of the tag:
1. Build the updated images
2. Tag it with the new `<integer>` (`docker tag`)
3. Push the new tag (`docker push`)
3. Update docs where the tags are referenced.
3. Merge the `develop` branch into the `staging` branch.
4. CI will automatically update the `latest` tag for both `octo` and `octopod`. Wait for CI to complete.
5. Deploy everything in our private cluser and make sure everything works.
6. Merge the `staging` branch into `master` using **Rebase and Merge**.
7. CI will automatically create a new release in GitHub with _octo CLI_ and update the `latest` tag for both `octo` and `octopod`. Wait for CI to complete.
8. Edit the created release in GitHub to match the version you are releasing.
1. Change the release name to the version being released.
2. Uncheck "This is a pre-release"
9. Push the new release of `octo` and `octopod`. To do this run `./release.sh <version>`.
2. If there were changes to control scripts:
1. _**\<TODO\>**_
3. [Dispatch the "Build and release" workflow](https://github.com/typeable/octopod/actions/workflows/build.yaml), specifying the version you are releasing:

![](./img/release_workflow.png)
Binary file added img/release_workflow.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 43d6f53

Please sign in to comment.