cerc-io/lighthouse
16
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity
18f3edff0a
lighthouse/.github/workflows/release.yml

291 lines
17 KiB
YAML
Raw Normal View History

add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
name: Release Suite
on:
push:
tags:
- v*
Use the native `concurrency` property to cancel workflows (#4572) I noticed that some of our workflows aren't getting cancelled when a new one has been triggered, so we ended up having a long queue in our CI when multiple changes are triggered in a short period. Looking at the comment here, I noticed the list of workflow IDs are outdated and no longer exist, and some new ones are missing: https://github.com/sigp/lighthouse/blob/dfcb3363c757671eb19d5f8e519b4b94ac74677a/.github/workflows/cancel-previous-runs.yml#L12-L13 I attempted to update these, and came across this comment on the [`cancel-workflow-action`](https://github.com/styfle/cancel-workflow-action) repo: > You probably don't need to install this custom action. > > Instead, use the native [concurrency](https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/) property to cancel workflows, for example: So I thought instead of updating the workflow and maintaining the workflow IDs, perhaps we can try experimenting the [native `concurrency` property](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency).
2023-08-14 03:16:03 +00:00
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
env:
Automate docker version tag (#2150) ## Issue Addressed N/A ## Proposed Changes On any tag formatted `v*`, a full multi-arch docker build will be kicked off and automatically pushed to docker hub with the version tag. This is a bit repetitive, because the image built will usually be the same as the image built on pushes to `stable`, but it seems like the simplest way to go about it and this will also work if we incorporate a workflow with `vX.X.X-rc` tags. ## Additional Info This may also need to wait for env variable updates: https://github.com/sigp/lighthouse/pull/2135#issuecomment-754977433 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-19 03:50:10 +00:00
DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
REPO_NAME: ${{ github.repository_owner }}/lighthouse
IMAGE_NAME: ${{ github.repository_owner }}/lighthouse
Fix release CI for self-hosted runners (#4770) ## Issue Addressed NA ## Proposed Changes Disables some commands for self-hosted runners to prevent failures. ## Additional Info NA
2023-09-22 11:04:47 +00:00
# Enable self-hosted runners for the sigp repo only.
SELF_HOSTED_RUNNERS: ${{ github.repository == 'sigp/lighthouse' }}
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
jobs:
extract-version:
runs-on: ubuntu-latest
steps:
- name: Extract version
CI gardening maintenance (#3706) ## Issue Addressed Closes https://github.com/sigp/lighthouse/issues/3656 ## Proposed Changes * Replace `set-output` by `$GITHUB_OUTPUT` usage * Avoid rate-limits when installing `protoc` by making authenticated requests (continuation of https://github.com/sigp/lighthouse/pull/3621) * Upgrade all Ubuntu 18.04 usage to 22.04 (18.04 is end of life) * Upgrade macOS-latest to explicit macOS-12 to silence warning * Use `actions/checkout@v3` and `actions/cache@v3` to avoid deprecated NodeJS v12 ## Additional Info Can't silence the NodeJS warnings entirely due to https://github.com/sigp/lighthouse/issues/3705. Can fix that in future.
2022-11-13 22:40:44 +00:00
run: echo "VERSION=$(echo ${GITHUB_REF#refs/tags/})" >> $GITHUB_OUTPUT
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
id: extract_version
outputs:
VERSION: ${{ steps.extract_version.outputs.VERSION }}
build:
name: Build Release
strategy:
matrix:
arch: [aarch64-unknown-linux-gnu,
aarch64-unknown-linux-gnu-portable,
x86_64-unknown-linux-gnu,
x86_64-unknown-linux-gnu-portable,
x86_64-apple-darwin,
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
x86_64-apple-darwin-portable,
x86_64-windows,
x86_64-windows-portable]
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
include:
- arch: aarch64-unknown-linux-gnu
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runner: ${{ github.repository == 'sigp/lighthouse' && fromJson('["self-hosted", "linux", "release", "large"]') || 'ubuntu-latest' }}
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
profile: maxperf
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
- arch: aarch64-unknown-linux-gnu-portable
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runner: ${{ github.repository == 'sigp/lighthouse' && fromJson('["self-hosted", "linux", "release", "large"]') || 'ubuntu-latest' }}
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
profile: maxperf
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
- arch: x86_64-unknown-linux-gnu
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runner: ${{ github.repository == 'sigp/lighthouse' && fromJson('["self-hosted", "linux", "release", "large"]') || 'ubuntu-latest' }}
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
profile: maxperf
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
- arch: x86_64-unknown-linux-gnu-portable
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runner: ${{ github.repository == 'sigp/lighthouse' && fromJson('["self-hosted", "linux", "release", "large"]') || 'ubuntu-latest' }}
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
profile: maxperf
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
- arch: x86_64-apple-darwin
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runner: macos-latest
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
profile: maxperf
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
- arch: x86_64-apple-darwin-portable
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runner: macos-latest
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
profile: maxperf
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
- arch: x86_64-windows
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runner: ${{ github.repository == 'sigp/lighthouse' && fromJson('["self-hosted", "windows", "release"]') || 'windows-2019' }}
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
profile: maxperf
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
- arch: x86_64-windows-portable
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runner: ${{ github.repository == 'sigp/lighthouse' && fromJson('["self-hosted", "windows", "release"]') || 'windows-2019' }}
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
profile: maxperf
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
Use release workflow runners (#4765) ## Issue Addressed Build releases on self-hosted hardware to speed the process up
2023-09-22 02:33:13 +00:00
runs-on: ${{ matrix.runner }}
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
needs: extract-version
steps:
- name: Checkout sources
CI gardening maintenance (#3706) ## Issue Addressed Closes https://github.com/sigp/lighthouse/issues/3656 ## Proposed Changes * Replace `set-output` by `$GITHUB_OUTPUT` usage * Avoid rate-limits when installing `protoc` by making authenticated requests (continuation of https://github.com/sigp/lighthouse/pull/3621) * Upgrade all Ubuntu 18.04 usage to 22.04 (18.04 is end of life) * Upgrade macOS-latest to explicit macOS-12 to silence warning * Use `actions/checkout@v3` and `actions/cache@v3` to avoid deprecated NodeJS v12 ## Additional Info Can't silence the NodeJS warnings entirely due to https://github.com/sigp/lighthouse/issues/3705. Can fix that in future.
2022-11-13 22:40:44 +00:00
uses: actions/checkout@v3
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
- name: Get latest version of stable Rust
Fix release CI for self-hosted runners (#4770) ## Issue Addressed NA ## Proposed Changes Disables some commands for self-hosted runners to prevent failures. ## Additional Info NA
2023-09-22 11:04:47 +00:00
if: env.SELF_HOSTED_RUNNERS == 'false'
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
run: rustup update stable
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
# ==============================
Release v2.1.0-rc.1 (#2921) ## Proposed Changes New release candidate to address Windows build failure for rc.0
2022-01-17 03:25:30 +00:00
# Windows dependencies
# ==============================
- uses: KyleMayes/install-llvm-action@v1
Fix release CI for self-hosted runners (#4770) ## Issue Addressed NA ## Proposed Changes Disables some commands for self-hosted runners to prevent failures. ## Additional Info NA
2023-09-22 11:04:47 +00:00
if: env.SELF_HOSTED_RUNNERS == 'false' && startsWith(matrix.arch, 'x86_64-windows')
Release v2.1.0-rc.1 (#2921) ## Proposed Changes New release candidate to address Windows build failure for rc.0
2022-01-17 03:25:30 +00:00
with:
Update LLVM version to 15.0 in CI workflows (#4220) ## Issue Addressed The latest stable version (1.69.0) of Rust was released on 20 April and contains this change: - [Update the minimum external LLVM to 14.](https://github.com/rust-lang/rust/pull/107573/) This impacts some of our CI workflows (build and release-test-windows) that uses LLVM 13.0. This PR updates the workflows to install LLVM 15.0. **UPDATE**: Also updated `h2` to address [this issue](https://github.com/advisories/GHSA-f8vr-r385-rh5r)
2023-04-21 18:29:27 +00:00
version: "15.0"
Release v2.1.0-rc.1 (#2921) ## Proposed Changes New release candidate to address Windows build failure for rc.0
2022-01-17 03:25:30 +00:00
directory: ${{ runner.temp }}/llvm
- name: Set LIBCLANG_PATH
if: startsWith(matrix.arch, 'x86_64-windows')
run: echo "LIBCLANG_PATH=$((gcm clang).source -replace "clang.exe")" >> $env:GITHUB_ENV
# ==============================
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
# Builds
# ==============================
Use cross in linux x86 64 release flow (#2136) ## Issue Addressed Resolves #2120 ## Proposed Changes This updates github actions to use `cross` when compiling linux x86_64 binaries. ## Additional Info I think we could alternatively be explicit with the version of macOS or ubuntu we are running actions on and that could solve #2120. I'm not sure which method is preferred here though. Github actions supports Ubuntu 16.04 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-12 06:38:22 +00:00
- name: Build Lighthouse for aarch64-unknown-linux-gnu-portable
if: matrix.arch == 'aarch64-unknown-linux-gnu-portable'
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
run: |
cargo install cross
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
env CROSS_PROFILE=${{ matrix.profile }} make build-aarch64-portable
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
Use cross in linux x86 64 release flow (#2136) ## Issue Addressed Resolves #2120 ## Proposed Changes This updates github actions to use `cross` when compiling linux x86_64 binaries. ## Additional Info I think we could alternatively be explicit with the version of macOS or ubuntu we are running actions on and that could solve #2120. I'm not sure which method is preferred here though. Github actions supports Ubuntu 16.04 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-12 06:38:22 +00:00
- name: Build Lighthouse for aarch64-unknown-linux-gnu
if: matrix.arch == 'aarch64-unknown-linux-gnu'
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
run: |
cargo install cross
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
env CROSS_PROFILE=${{ matrix.profile }} make build-aarch64
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
Use cross in linux x86 64 release flow (#2136) ## Issue Addressed Resolves #2120 ## Proposed Changes This updates github actions to use `cross` when compiling linux x86_64 binaries. ## Additional Info I think we could alternatively be explicit with the version of macOS or ubuntu we are running actions on and that could solve #2120. I'm not sure which method is preferred here though. Github actions supports Ubuntu 16.04 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-12 06:38:22 +00:00
- name: Build Lighthouse for x86_64-unknown-linux-gnu-portable
if: matrix.arch == 'x86_64-unknown-linux-gnu-portable'
run: |
cargo install cross
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
env CROSS_PROFILE=${{ matrix.profile }} make build-x86_64-portable
Use cross in linux x86 64 release flow (#2136) ## Issue Addressed Resolves #2120 ## Proposed Changes This updates github actions to use `cross` when compiling linux x86_64 binaries. ## Additional Info I think we could alternatively be explicit with the version of macOS or ubuntu we are running actions on and that could solve #2120. I'm not sure which method is preferred here though. Github actions supports Ubuntu 16.04 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-12 06:38:22 +00:00
- name: Build Lighthouse for x86_64-unknown-linux-gnu
if: matrix.arch == 'x86_64-unknown-linux-gnu'
run: |
cargo install cross
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
env CROSS_PROFILE=${{ matrix.profile }} make build-x86_64
Use cross in linux x86 64 release flow (#2136) ## Issue Addressed Resolves #2120 ## Proposed Changes This updates github actions to use `cross` when compiling linux x86_64 binaries. ## Additional Info I think we could alternatively be explicit with the version of macOS or ubuntu we are running actions on and that could solve #2120. I'm not sure which method is preferred here though. Github actions supports Ubuntu 16.04 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-12 06:38:22 +00:00
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
- name: Move cross-compiled binary
if: startsWith(matrix.arch, 'aarch64')
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
run: mv target/aarch64-unknown-linux-gnu/${{ matrix.profile }}/lighthouse ~/.cargo/bin/lighthouse
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
Use cross in linux x86 64 release flow (#2136) ## Issue Addressed Resolves #2120 ## Proposed Changes This updates github actions to use `cross` when compiling linux x86_64 binaries. ## Additional Info I think we could alternatively be explicit with the version of macOS or ubuntu we are running actions on and that could solve #2120. I'm not sure which method is preferred here though. Github actions supports Ubuntu 16.04 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-12 06:38:22 +00:00
- name: Move cross-compiled binary
if: startsWith(matrix.arch, 'x86_64-unknown-linux-gnu')
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
run: mv target/x86_64-unknown-linux-gnu/${{ matrix.profile }}/lighthouse ~/.cargo/bin/lighthouse
Use cross in linux x86 64 release flow (#2136) ## Issue Addressed Resolves #2120 ## Proposed Changes This updates github actions to use `cross` when compiling linux x86_64 binaries. ## Additional Info I think we could alternatively be explicit with the version of macOS or ubuntu we are running actions on and that could solve #2120. I'm not sure which method is preferred here though. Github actions supports Ubuntu 16.04 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-12 06:38:22 +00:00
- name: Build Lighthouse for x86_64-apple-darwin portable
if: matrix.arch == 'x86_64-apple-darwin-portable'
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
run: cargo install --path lighthouse --force --locked --features portable,gnosis --profile ${{ matrix.profile }}
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
Use cross in linux x86 64 release flow (#2136) ## Issue Addressed Resolves #2120 ## Proposed Changes This updates github actions to use `cross` when compiling linux x86_64 binaries. ## Additional Info I think we could alternatively be explicit with the version of macOS or ubuntu we are running actions on and that could solve #2120. I'm not sure which method is preferred here though. Github actions supports Ubuntu 16.04 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-12 06:38:22 +00:00
- name: Build Lighthouse for x86_64-apple-darwin modern
if: matrix.arch == 'x86_64-apple-darwin'
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
run: cargo install --path lighthouse --force --locked --features modern,gnosis --profile ${{ matrix.profile }}
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
- name: Build Lighthouse for Windows portable
if: matrix.arch == 'x86_64-windows-portable'
Re-enable maxperf for Windows releases (#4371) ## Issue Addressed Closes #3964 ## Proposed Changes Use the `maxperf` profile to build Windows binaries, now that Rust 1.70.0 fixed the underlying issue.
2023-06-14 02:29:51 +00:00
run: cargo install --path lighthouse --force --locked --features portable,gnosis --profile ${{ matrix.profile }}
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
- name: Build Lighthouse for Windows modern
if: matrix.arch == 'x86_64-windows'
Re-enable maxperf for Windows releases (#4371) ## Issue Addressed Closes #3964 ## Proposed Changes Use the `maxperf` profile to build Windows binaries, now that Rust 1.70.0 fixed the underlying issue.
2023-06-14 02:29:51 +00:00
run: cargo install --path lighthouse --force --locked --features modern,gnosis --profile ${{ matrix.profile }}
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
- name: Configure GPG and create artifacts
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
if: startsWith(matrix.arch, 'x86_64-windows') != true
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
env:
GPG_SIGNING_KEY: ${{ secrets.GPG_SIGNING_KEY }}
GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}
run: |
export GPG_TTY=$(tty)
echo "$GPG_SIGNING_KEY" | gpg --batch --import
mkdir artifacts
mv ~/.cargo/bin/lighthouse ./artifacts
cd artifacts
tar -czf lighthouse-${{ needs.extract-version.outputs.VERSION }}-${{ matrix.arch }}.tar.gz lighthouse
echo "$GPG_PASSPHRASE" | gpg --passphrase-fd 0 --pinentry-mode loopback --batch -ab lighthouse-${{ needs.extract-version.outputs.VERSION }}-${{ matrix.arch }}.tar.gz
mv *tar.gz* ..
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
- name: Configure GPG and create artifacts Windows
if: startsWith(matrix.arch, 'x86_64-windows')
env:
GPG_SIGNING_KEY: ${{ secrets.GPG_SIGNING_KEY }}
GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}
run: |
echo $env:GPG_SIGNING_KEY | gpg --batch --import
mkdir artifacts
move $env:USERPROFILE/.cargo/bin/lighthouse.exe ./artifacts
cd artifacts
tar -czf lighthouse-${{ needs.extract-version.outputs.VERSION }}-${{ matrix.arch }}.tar.gz lighthouse.exe
gpg --passphrase "$env:GPG_PASSPHRASE" --batch --pinentry-mode loopback -ab lighthouse-${{ needs.extract-version.outputs.VERSION }}-${{ matrix.arch }}.tar.gz
move *tar.gz* ..
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
# =======================================================================
# Upload artifacts
# This is required to share artifacts between different jobs
# =======================================================================
- name: Upload artifact
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
uses: actions/upload-artifact@v3
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
with:
name: lighthouse-${{ needs.extract-version.outputs.VERSION }}-${{ matrix.arch }}.tar.gz
path: lighthouse-${{ needs.extract-version.outputs.VERSION }}-${{ matrix.arch }}.tar.gz
- name: Upload signature
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
uses: actions/upload-artifact@v3
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
with:
name: lighthouse-${{ needs.extract-version.outputs.VERSION }}-${{ matrix.arch }}.tar.gz.asc
path: lighthouse-${{ needs.extract-version.outputs.VERSION }}-${{ matrix.arch }}.tar.gz.asc
draft-release:
name: Draft Release
needs: [build, extract-version]
runs-on: ubuntu-latest
env:
VERSION: ${{ needs.extract-version.outputs.VERSION }}
steps:
# This is necessary for generating the changelog. It has to come before "Download Artifacts" or else it deletes the artifacts.
- name: Checkout sources
CI gardening maintenance (#3706) ## Issue Addressed Closes https://github.com/sigp/lighthouse/issues/3656 ## Proposed Changes * Replace `set-output` by `$GITHUB_OUTPUT` usage * Avoid rate-limits when installing `protoc` by making authenticated requests (continuation of https://github.com/sigp/lighthouse/pull/3621) * Upgrade all Ubuntu 18.04 usage to 22.04 (18.04 is end of life) * Upgrade macOS-latest to explicit macOS-12 to silence warning * Use `actions/checkout@v3` and `actions/cache@v3` to avoid deprecated NodeJS v12 ## Additional Info Can't silence the NodeJS warnings entirely due to https://github.com/sigp/lighthouse/issues/3705. Can fix that in future.
2022-11-13 22:40:44 +00:00
uses: actions/checkout@v3
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
with:
fetch-depth: 0
# ==============================
# Download artifacts
# ==============================
- name: Download artifacts
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
uses: actions/download-artifact@v3
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
# ==============================
# Create release draft
# ==============================
- name: Generate Full Changelog
id: changelog
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
run: |
echo "CHANGELOG<<EOF" >> $GITHUB_OUTPUT
echo "$(git log --pretty=format:"- %s" $(git describe --tags --abbrev=0 ${{ env.VERSION }}^)..${{ env.VERSION }})" >> $GITHUB_OUTPUT
echo "EOF" >> $GITHUB_OUTPUT
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
- name: Create Release Draft
env:
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
GITHUB_USER: ${{ github.repository_owner }}
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# The formatting here is borrowed from OpenEthereum: https://github.com/openethereum/openethereum/blob/main/.github/workflows/build.yml
run: |
body=$(cat <<- "ENDBODY"
<Rick and Morty character>
Start a release checklist (#2270) ## Issue Addressed NA ## Proposed Changes Add a checklist to the release draft created by CI. I know @michaelsproul was also working on this and I suspect @realbigsean also might have useful input. ## Additional Info NA
2021-07-12 10:02:25 +00:00
## Testing Checklist (DELETE ME)
Add maxperf build profile (#3608) ## Proposed Changes Add a new Cargo compilation profile called `maxperf` which enables more aggressive compiler optimisations at the expense of compilation time. Some rough initial benchmarks show that this can provide up to a 25% reduction to run time for CPU bound tasks like block processing: https://docs.google.com/spreadsheets/d/15jHuZe7lLHhZq9Nw8kc6EL0Qh_N_YAYqkW2NQ_Afmtk/edit The numbers in that spreadsheet compare the `consensus-context` branch from #3604 to the same branch compiled with the `maxperf` profile using: ``` PROFILE=maxperf make install-lcli ``` ## Additional Info The downsides of the maxperf profile are: - It increases compile times substantially, which will particularly impact low-spec hardware. Compiling `lcli` is about 3x slower. Compiling Lighthouse is about 5x slower on my 5950X: 17m 38s rather than 3m 28s. As a result I think we should not enable this everywhere by default. - **Option 1**: enable by default for our released binaries. This gives the majority of users the fastest version of `lighthouse` possible, at the expense of slowing down our release CI. Source builds will continue to use the default `release` profile unless users opt-in to `maxperf`. - **Option 2**: enable by default for source builds. This gives users building from source an edge, but makes them pay for it with compilation time. I think I would prefer Option 1. I'll try doing some benchmarking to see how long a maxperf build of Lighthouse would take on GitHub actions. Credit to Nicholas Nethercote for documenting these options in the Rust Performance Book: https://nnethercote.github.io/perf-book/build-configuration.html.
2022-09-29 06:13:33 +00:00
Start a release checklist (#2270) ## Issue Addressed NA ## Proposed Changes Add a checklist to the release draft created by CI. I know @michaelsproul was also working on this and I suspect @realbigsean also might have useful input. ## Additional Info NA
2021-07-12 10:02:25 +00:00
- [ ] Run on synced Prater Sigma Prime nodes.
- [ ] Run on synced Canary (mainnet) Sigma Prime nodes.
- [ ] Resync a Prater node.
- [ ] Resync a mainnet node.
## Release Checklist (DELETE ME)
- [ ] Merge `unstable` -> `stable`.
- [ ] Ensure docker images are published (check `latest` and the version tag).
- [ ] Prepare Discord post.
- [ ] Prepare Twitter post.
- [ ] Prepare mailing list email.
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
## Summary
Add a summary.
Add "update priority" (#2988) ## Issue Addressed NA ## Proposed Changes Add the "Update Priority" section which has featured in many of our previous releases (e.g., [Poñeta](https://github.com/sigp/lighthouse/releases/v2.1.1)). Previously this section has been copied in manually. ## Additional Info NA
2022-02-09 07:44:42 +00:00
## Update Priority
This table provides priorities for which classes of users should update particular components.
|User Class |Beacon Node | Validator Client|
--- | --- | ---
|Staking Users| <TODO> | <TODO> |
|Non-Staking Users| <TODO>|---|
*See [Update
Priorities](https://lighthouse-book.sigmaprime.io/installation-priorities.html)
more information about this table.*
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
## All Changes
${{ steps.changelog.outputs.CHANGELOG }}
## Binaries
[See pre-built binaries documentation.](https://lighthouse-book.sigmaprime.io/installation-binaries.html)
The binaries are signed with Sigma Prime's PGP key: `15E66D941F697E28F49381F426416DC3F30674B0`
| System | Architecture | Binary | PGP Signature |
|:---:|:---:|:---:|:---|
| <img src="https://simpleicons.org/icons/apple.svg" style="width: 32px;"/> | x86_64 | [lighthouse-${{ env.VERSION }}-x86_64-apple-darwin.tar.gz](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-apple-darwin.tar.gz) | [PGP Signature](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-apple-darwin.tar.gz.asc) |
| <img src="https://simpleicons.org/icons/apple.svg" style="width: 32px;"/> | x86_64 | [lighthouse-${{ env.VERSION }}-x86_64-apple-darwin-portable.tar.gz](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-apple-darwin-portable.tar.gz) | [PGP Signature](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-apple-darwin-portable.tar.gz.asc) |
| <img src="https://simpleicons.org/icons/linux.svg" style="width: 32px;"/> | x86_64 | [lighthouse-${{ env.VERSION }}-x86_64-unknown-linux-gnu.tar.gz](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-unknown-linux-gnu.tar.gz) | [PGP Signature](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-unknown-linux-gnu.tar.gz.asc) |
| <img src="https://simpleicons.org/icons/linux.svg" style="width: 32px;"/> | x86_64 | [lighthouse-${{ env.VERSION }}-x86_64-unknown-linux-gnu-portable.tar.gz](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-unknown-linux-gnu-portable.tar.gz) | [PGP Signature](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-unknown-linux-gnu-portable.tar.gz.asc) |
| <img src="https://simpleicons.org/icons/raspberrypi.svg" style="width: 32px;"/> | aarch64 | [lighthouse-${{ env.VERSION }}-aarch64-unknown-linux-gnu.tar.gz](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-aarch64-unknown-linux-gnu.tar.gz) | [PGP Signature](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-aarch64-unknown-linux-gnu.tar.gz.asc) |
| <img src="https://simpleicons.org/icons/raspberrypi.svg" style="width: 32px;"/> | aarch64 | [lighthouse-${{ env.VERSION }}-aarch64-unknown-linux-gnu-portable.tar.gz](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-aarch64-unknown-linux-gnu-portable.tar.gz) | [PGP Signature](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-aarch64-unknown-linux-gnu-portable.tar.gz.asc) |
Windows binaries (#2492) ## Issue Addressed Resolves #2406 ## Proposed Changes Add windows release binaries to our CI ## Additional Info Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-08-24 01:36:26 +00:00
| <img src="https://simpleicons.org/icons/windows.svg" style="width: 32px;"/> | x86_64 | [lighthouse-${{ env.VERSION }}-x86_64-windows.tar.gz](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-windows.tar.gz) | [PGP Signature](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-windows.tar.gz.asc) |
| <img src="https://simpleicons.org/icons/windows.svg" style="width: 32px;"/> | x86_64 | [lighthouse-${{ env.VERSION }}-x86_64-windows-portable.tar.gz](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-windows-portable.tar.gz) | [PGP Signature](https://github.com/${{ env.REPO_NAME }}/releases/download/${{ env.VERSION }}/lighthouse-${{ env.VERSION }}-x86_64-windows-portable.tar.gz.asc) |
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
| | | | |
| **System** | **Option** | - | **Resource** |
Automate docker version tag (#2150) ## Issue Addressed N/A ## Proposed Changes On any tag formatted `v*`, a full multi-arch docker build will be kicked off and automatically pushed to docker hub with the version tag. This is a bit repetitive, because the image built will usually be the same as the image built on pushes to `stable`, but it seems like the simplest way to go about it and this will also work if we incorporate a workflow with `vX.X.X-rc` tags. ## Additional Info This may also need to wait for env variable updates: https://github.com/sigp/lighthouse/pull/2135#issuecomment-754977433 Co-authored-by: realbigsean <seananderson33@gmail.com>
2021-01-19 03:50:10 +00:00
| <img src="https://simpleicons.org/icons/docker.svg" style="width: 32px;"/> | Docker | [${{ env.VERSION }}](https://hub.docker.com/r/${{ env.IMAGE_NAME }}/tags?page=1&ordering=last_updated&name=${{ env.VERSION }}) | [${{ env.IMAGE_NAME }}](https://hub.docker.com/r/${{ env.IMAGE_NAME }}) |
add automated release workflow (#2077) ## Issue Addressed Resolves #1674 ## Proposed Changes - Whenever a tag is pushed with the prefix `v` this workflow is triggered - creates portable and non-portable binaries for linux x86_64, linux aarch64, macOS - an attempt at using github actions caching - signs each binary using GPG - auto-generates full changelog based on commit messages since the last release - creates a **draft** release - hot new formatting (preview [here](https://github.com/realbigsean/lighthouse/releases/tag/v0.9.23)) - has been taking around 35 minutes ## Additional Info TODOs: - Figure out how we should automate dockerhub's version tag. - It'd be quickest just to tag `latest`, but we'd need to make sure the docker workflow completes before this starts - we do the same cross-compile in the `docker` workflow, we could try to use the same binary - integrate a similar flow for unstable binaries (`-rc` tag?) - improve caching, potentially use sccache - if we start using a self-hosted runner this'll require some re-working Need to add the following secrets to Github: - `GPG_PASSPHRASE` - ~~`GPG_PUBLIC_KEY`~~ hard-coded this, because it was tough manage as a secret - `GPG_SIGNING_KEY` Co-authored-by: realbigsean <seananderson33@gmail.com>
2020-12-23 07:53:34 +00:00
ENDBODY
)
assets=()
for asset in ./lighthouse-*.tar.gz*; do
assets+=("-a" "$asset/$asset")
done
tag_name="${{ env.VERSION }}"
echo "$body" | hub release create --draft "${assets[@]}" -F "-" "$tag_name"
Reference in New Issue Copy Permalink