2021-06-09 23:21:08 +03:00
|
|
|
name: "publish-release"
|
|
|
|
|
|
|
|
on:
|
Introduce tag-based draft releases (#117)
The release scheme is as follows.
## Tags
A release is created on a tag push. The tag must be prefixed with `v`, e.g., `v0.2.3`.
Tags can be pushed either manually or via `tag.yml` GitHub Action via a press of the button.
Tags can be moved if needed, like this:
```
# Remove tag
git push -d origin v0.2.3 && git tag -d v0.2.3
# Mark current commit with a tag and push
git tag v0.2.3 && git push origin v0.2.3
```
In such a case, the release action will be executed against the new commit and the existing `v0.2.3` release will be moved to Draft status. One would rarely need such a trick, but it's useful to know of it.
## Changelog
On each release, a changelog is generated. The changelog is calculated from Pull Requests merged between a previous semver-looking tag and a newly pushed one. So, given that there was a release `v0.2.2`, on a push of `v0.2.3` changelog will be generated from PRs that were merged since `v0.2.2` until the commit marked with `v0.2.3`.
Changelog format can be easily changed in the `changelog_config.json` file. It is also possible to set up PR grouping by labels or by regex.
## Release
GitHub release is created in status 'Draft' to avoid notifying repository watchers. Repository maintainers must review the release and make it public manually.
## Publishing
On each release, all publishable crates are published to crates.io. Their versions are published as is, i.e. exactly as specified in Cargo.toml's. Because of that, it is possible that the same versions of crates exist in different releases. It gives maintainers the finest control over publishing.
2021-09-15 18:52:31 +03:00
|
|
|
push:
|
|
|
|
tags:
|
|
|
|
- "v*"
|
2021-06-09 23:21:08 +03:00
|
|
|
|
|
|
|
jobs:
|
|
|
|
npm-publish:
|
|
|
|
name: "Publish release"
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
defaults:
|
|
|
|
run:
|
|
|
|
shell: bash
|
|
|
|
|
|
|
|
steps:
|
|
|
|
- name: Checkout repository
|
|
|
|
uses: actions/checkout@v2
|
|
|
|
|
|
|
|
### Prepare cargo & toolchains
|
|
|
|
- uses: actions/cache@v2
|
|
|
|
with:
|
|
|
|
path: |
|
|
|
|
~/.cargo/registry
|
|
|
|
~/.cargo/git
|
|
|
|
~/.cargo/bin
|
|
|
|
target
|
|
|
|
key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
|
|
|
|
- name: Install Rust toolchain
|
|
|
|
uses: actions-rs/toolchain@v1
|
|
|
|
with:
|
|
|
|
toolchain: nightly
|
|
|
|
profile: minimal
|
|
|
|
override: true
|
|
|
|
- uses: actions-rs/cargo@v1
|
|
|
|
with:
|
|
|
|
toolchain: nightly
|
|
|
|
command: update
|
|
|
|
args: --aggressive
|
|
|
|
|
|
|
|
- name: Install cargo-workspaces
|
|
|
|
run: cargo install cargo-workspaces || true
|
|
|
|
|
|
|
|
### === Rust package release ===
|
|
|
|
- name: Login to crates.io
|
|
|
|
run: cargo login ${{ secrets.CRATES_IO_TOKEN }}
|
|
|
|
|
|
|
|
- name: Save crate version to env
|
|
|
|
run: |
|
|
|
|
set -x
|
|
|
|
PKG_NAME=marine
|
Introduce tag-based draft releases (#117)
The release scheme is as follows.
## Tags
A release is created on a tag push. The tag must be prefixed with `v`, e.g., `v0.2.3`.
Tags can be pushed either manually or via `tag.yml` GitHub Action via a press of the button.
Tags can be moved if needed, like this:
```
# Remove tag
git push -d origin v0.2.3 && git tag -d v0.2.3
# Mark current commit with a tag and push
git tag v0.2.3 && git push origin v0.2.3
```
In such a case, the release action will be executed against the new commit and the existing `v0.2.3` release will be moved to Draft status. One would rarely need such a trick, but it's useful to know of it.
## Changelog
On each release, a changelog is generated. The changelog is calculated from Pull Requests merged between a previous semver-looking tag and a newly pushed one. So, given that there was a release `v0.2.2`, on a push of `v0.2.3` changelog will be generated from PRs that were merged since `v0.2.2` until the commit marked with `v0.2.3`.
Changelog format can be easily changed in the `changelog_config.json` file. It is also possible to set up PR grouping by labels or by regex.
## Release
GitHub release is created in status 'Draft' to avoid notifying repository watchers. Repository maintainers must review the release and make it public manually.
## Publishing
On each release, all publishable crates are published to crates.io. Their versions are published as is, i.e. exactly as specified in Cargo.toml's. Because of that, it is possible that the same versions of crates exist in different releases. It gives maintainers the finest control over publishing.
2021-09-15 18:52:31 +03:00
|
|
|
WS_LIST=$(cargo ws list -l)
|
2021-06-09 23:21:08 +03:00
|
|
|
# substr(x, 2) removes first character from x. In case of version it's 'v' in 'v0.0.0'
|
Introduce tag-based draft releases (#117)
The release scheme is as follows.
## Tags
A release is created on a tag push. The tag must be prefixed with `v`, e.g., `v0.2.3`.
Tags can be pushed either manually or via `tag.yml` GitHub Action via a press of the button.
Tags can be moved if needed, like this:
```
# Remove tag
git push -d origin v0.2.3 && git tag -d v0.2.3
# Mark current commit with a tag and push
git tag v0.2.3 && git push origin v0.2.3
```
In such a case, the release action will be executed against the new commit and the existing `v0.2.3` release will be moved to Draft status. One would rarely need such a trick, but it's useful to know of it.
## Changelog
On each release, a changelog is generated. The changelog is calculated from Pull Requests merged between a previous semver-looking tag and a newly pushed one. So, given that there was a release `v0.2.2`, on a push of `v0.2.3` changelog will be generated from PRs that were merged since `v0.2.2` until the commit marked with `v0.2.3`.
Changelog format can be easily changed in the `changelog_config.json` file. It is also possible to set up PR grouping by labels or by regex.
## Release
GitHub release is created in status 'Draft' to avoid notifying repository watchers. Repository maintainers must review the release and make it public manually.
## Publishing
On each release, all publishable crates are published to crates.io. Their versions are published as is, i.e. exactly as specified in Cargo.toml's. Because of that, it is possible that the same versions of crates exist in different releases. It gives maintainers the finest control over publishing.
2021-09-15 18:52:31 +03:00
|
|
|
VERSION=$(echo $WS_LIST | grep "$PKG_NAME " | head -n1 | awk '{ print substr($2, 2) }')
|
2021-06-09 23:21:08 +03:00
|
|
|
echo "VERSION=$VERSION" | tee -a $GITHUB_ENV
|
|
|
|
echo "PKG_NAME=$PKG_NAME" | tee -a $GITHUB_ENV
|
Introduce tag-based draft releases (#117)
The release scheme is as follows.
## Tags
A release is created on a tag push. The tag must be prefixed with `v`, e.g., `v0.2.3`.
Tags can be pushed either manually or via `tag.yml` GitHub Action via a press of the button.
Tags can be moved if needed, like this:
```
# Remove tag
git push -d origin v0.2.3 && git tag -d v0.2.3
# Mark current commit with a tag and push
git tag v0.2.3 && git push origin v0.2.3
```
In such a case, the release action will be executed against the new commit and the existing `v0.2.3` release will be moved to Draft status. One would rarely need such a trick, but it's useful to know of it.
## Changelog
On each release, a changelog is generated. The changelog is calculated from Pull Requests merged between a previous semver-looking tag and a newly pushed one. So, given that there was a release `v0.2.2`, on a push of `v0.2.3` changelog will be generated from PRs that were merged since `v0.2.2` until the commit marked with `v0.2.3`.
Changelog format can be easily changed in the `changelog_config.json` file. It is also possible to set up PR grouping by labels or by regex.
## Release
GitHub release is created in status 'Draft' to avoid notifying repository watchers. Repository maintainers must review the release and make it public manually.
## Publishing
On each release, all publishable crates are published to crates.io. Their versions are published as is, i.e. exactly as specified in Cargo.toml's. Because of that, it is possible that the same versions of crates exist in different releases. It gives maintainers the finest control over publishing.
2021-09-15 18:52:31 +03:00
|
|
|
|
|
|
|
# write WS_LIST to GITHUB_ENV. It's a multiline variable, that's why we need HEREDOC stuff (<<EOF)
|
|
|
|
echo "WS_LIST<<EOF" >> $GITHUB_ENV
|
|
|
|
echo "$WS_LIST" >> $GITHUB_ENV
|
|
|
|
echo "EOF" >> $GITHUB_ENV
|
2021-06-09 23:21:08 +03:00
|
|
|
|
2021-07-05 14:50:43 +03:00
|
|
|
- name: Publish to crates.io
|
|
|
|
run: cargo ws publish --no-git-commit --from-git --skip-published --yes
|
2021-06-09 23:21:08 +03:00
|
|
|
|
|
|
|
- name: Build release binaries of marine & mrepl
|
|
|
|
run: cargo build --release -p marine -p mrepl
|
|
|
|
|
Introduce tag-based draft releases (#117)
The release scheme is as follows.
## Tags
A release is created on a tag push. The tag must be prefixed with `v`, e.g., `v0.2.3`.
Tags can be pushed either manually or via `tag.yml` GitHub Action via a press of the button.
Tags can be moved if needed, like this:
```
# Remove tag
git push -d origin v0.2.3 && git tag -d v0.2.3
# Mark current commit with a tag and push
git tag v0.2.3 && git push origin v0.2.3
```
In such a case, the release action will be executed against the new commit and the existing `v0.2.3` release will be moved to Draft status. One would rarely need such a trick, but it's useful to know of it.
## Changelog
On each release, a changelog is generated. The changelog is calculated from Pull Requests merged between a previous semver-looking tag and a newly pushed one. So, given that there was a release `v0.2.2`, on a push of `v0.2.3` changelog will be generated from PRs that were merged since `v0.2.2` until the commit marked with `v0.2.3`.
Changelog format can be easily changed in the `changelog_config.json` file. It is also possible to set up PR grouping by labels or by regex.
## Release
GitHub release is created in status 'Draft' to avoid notifying repository watchers. Repository maintainers must review the release and make it public manually.
## Publishing
On each release, all publishable crates are published to crates.io. Their versions are published as is, i.e. exactly as specified in Cargo.toml's. Because of that, it is possible that the same versions of crates exist in different releases. It gives maintainers the finest control over publishing.
2021-09-15 18:52:31 +03:00
|
|
|
- name: Build Changelog
|
|
|
|
id: changelog
|
|
|
|
uses: mikepenz/release-changelog-builder-action@v1
|
|
|
|
with:
|
|
|
|
configuration: ".github/workflows/changelog_config.json"
|
|
|
|
env:
|
|
|
|
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
|
|
|
|
|
|
|
- name: Build packages link list
|
|
|
|
id: link_list
|
|
|
|
uses: actions/github-script@v4
|
|
|
|
with:
|
|
|
|
github-token: ${{ secrets.GITHUB_TOKEN }}
|
|
|
|
result-encoding: string
|
|
|
|
script: |
|
|
|
|
try {
|
|
|
|
let ws_list = `${{ env.WS_LIST }}`
|
|
|
|
console.log("ws_list: ", ws_list);
|
|
|
|
let lines = ws_list.split("\n");
|
|
|
|
let columns = lines.map(l => l.split(' ').filter(e => e.length > 0));
|
|
|
|
let link_list = columns.map(line =>
|
|
|
|
`- [${line[0]} ${line[1]}](https://crates.io/crates/${line[0]}/${line[1]})`
|
|
|
|
).join('\n');
|
|
|
|
return link_list;
|
|
|
|
} catch (e) {
|
|
|
|
console.log("Err: " + e);
|
|
|
|
throw e;
|
|
|
|
}
|
2021-06-09 23:21:08 +03:00
|
|
|
|
|
|
|
- name: Release
|
|
|
|
uses: softprops/action-gh-release@v1
|
|
|
|
with:
|
|
|
|
name: Marine WASM Runtime ${{ env.VERSION }}
|
|
|
|
tag_name: ${{ env.VERSION }}
|
|
|
|
body: |
|
Introduce tag-based draft releases (#117)
The release scheme is as follows.
## Tags
A release is created on a tag push. The tag must be prefixed with `v`, e.g., `v0.2.3`.
Tags can be pushed either manually or via `tag.yml` GitHub Action via a press of the button.
Tags can be moved if needed, like this:
```
# Remove tag
git push -d origin v0.2.3 && git tag -d v0.2.3
# Mark current commit with a tag and push
git tag v0.2.3 && git push origin v0.2.3
```
In such a case, the release action will be executed against the new commit and the existing `v0.2.3` release will be moved to Draft status. One would rarely need such a trick, but it's useful to know of it.
## Changelog
On each release, a changelog is generated. The changelog is calculated from Pull Requests merged between a previous semver-looking tag and a newly pushed one. So, given that there was a release `v0.2.2`, on a push of `v0.2.3` changelog will be generated from PRs that were merged since `v0.2.2` until the commit marked with `v0.2.3`.
Changelog format can be easily changed in the `changelog_config.json` file. It is also possible to set up PR grouping by labels or by regex.
## Release
GitHub release is created in status 'Draft' to avoid notifying repository watchers. Repository maintainers must review the release and make it public manually.
## Publishing
On each release, all publishable crates are published to crates.io. Their versions are published as is, i.e. exactly as specified in Cargo.toml's. Because of that, it is possible that the same versions of crates exist in different releases. It gives maintainers the finest control over publishing.
2021-09-15 18:52:31 +03:00
|
|
|
${{steps.changelog.outputs.changelog}}
|
|
|
|
|
|
|
|
## crates.io
|
|
|
|
${{ steps.link_list.outputs.result }}
|
2021-06-09 23:21:08 +03:00
|
|
|
files: |
|
|
|
|
target/release/marine
|
|
|
|
target/release/mrepl
|
Introduce tag-based draft releases (#117)
The release scheme is as follows.
## Tags
A release is created on a tag push. The tag must be prefixed with `v`, e.g., `v0.2.3`.
Tags can be pushed either manually or via `tag.yml` GitHub Action via a press of the button.
Tags can be moved if needed, like this:
```
# Remove tag
git push -d origin v0.2.3 && git tag -d v0.2.3
# Mark current commit with a tag and push
git tag v0.2.3 && git push origin v0.2.3
```
In such a case, the release action will be executed against the new commit and the existing `v0.2.3` release will be moved to Draft status. One would rarely need such a trick, but it's useful to know of it.
## Changelog
On each release, a changelog is generated. The changelog is calculated from Pull Requests merged between a previous semver-looking tag and a newly pushed one. So, given that there was a release `v0.2.2`, on a push of `v0.2.3` changelog will be generated from PRs that were merged since `v0.2.2` until the commit marked with `v0.2.3`.
Changelog format can be easily changed in the `changelog_config.json` file. It is also possible to set up PR grouping by labels or by regex.
## Release
GitHub release is created in status 'Draft' to avoid notifying repository watchers. Repository maintainers must review the release and make it public manually.
## Publishing
On each release, all publishable crates are published to crates.io. Their versions are published as is, i.e. exactly as specified in Cargo.toml's. Because of that, it is possible that the same versions of crates exist in different releases. It gives maintainers the finest control over publishing.
2021-09-15 18:52:31 +03:00
|
|
|
draft: true
|
2021-06-09 23:21:08 +03:00
|
|
|
prerelease: false
|
|
|
|
fail_on_unmatched_files: true
|
|
|
|
env:
|
|
|
|
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|