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

299 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*
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
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
platform: 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
platform: 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
platform: 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
platform: 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
platform: 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
platform: 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 windows-2019 in release CI (#3090) ## Issue Addressed NA ## Proposed Changes Address a CI failure in the release suite. Example: https://github.com/sigp/lighthouse/actions/runs/1984266187 ## Additional Info I believe we should merge this into `unstable` and `stable`. Then, move the `v2.1.4` commit to target the commit with the updated CI. It's sad that v2.1.4 has two commits, but they're functionally equivalent for users.
2022-03-15 03:21:11 +00:00
platform: 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 windows-2019 in release CI (#3090) ## Issue Addressed NA ## Proposed Changes Address a CI failure in the release suite. Example: https://github.com/sigp/lighthouse/actions/runs/1984266187 ## Additional Info I believe we should merge this into `unstable` and `stable`. Then, move the `v2.1.4` commit to target the commit with the updated CI. It's sad that v2.1.4 has two commits, but they're functionally equivalent for users.
2022-03-15 03:21:11 +00:00
platform: 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
runs-on: ${{ matrix.platform }}
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
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
if: startsWith(matrix.arch, 'x86_64-windows')
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
Ensure protoc is installed for release CI (#3621) ## Issue Addressed The release CI is currently broken due to the addition of the `protoc` dependency. Here's a failure of the release flow running on my fork: https://github.com/michaelsproul/lighthouse/actions/runs/3155541478/jobs/5134317334 ## Proposed Changes - Install `protoc` on Windows and Mac so that it's available for `cargo install`. - Install an x86_64 binary in the Cross image for the aarch64 platform: we need a binary that runs on the host, _not_ on the target. - Fix `macos` local testnet CI by using the Github API key to dodge rate limiting (this issue: https://github.com/actions/runner-images/issues/602).
2022-10-03 23:09:25 +00:00
# ==============================
# Windows & Mac dependencies
# ==============================
- name: Install Protoc
if: contains(matrix.arch, 'darwin') || contains(matrix.arch, 'windows')
Various CI fixes (#3813) ## Issue Addressed Closes #3812 Closes #3750 Closes #3705
2022-12-20 01:34:52 +00:00
uses: arduino/setup-protoc@e52d9eb8f7b63115df1ac544a1376fdbf5a39612
Ensure protoc is installed for release CI (#3621) ## Issue Addressed The release CI is currently broken due to the addition of the `protoc` dependency. Here's a failure of the release flow running on my fork: https://github.com/michaelsproul/lighthouse/actions/runs/3155541478/jobs/5134317334 ## Proposed Changes - Install `protoc` on Windows and Mac so that it's available for `cargo install`. - Install an x86_64 binary in the Cross image for the aarch64 platform: we need a binary that runs on the host, _not_ on the target. - Fix `macos` local testnet CI by using the Github API key to dodge rate limiting (this issue: https://github.com/actions/runner-images/issues/602).
2022-10-03 23:09:25 +00:00
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
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
# ==============================
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'
Use release profile for Windows binaries (#3965) ## Proposed Changes Disable `maxperf` profile on Windows due to #3964. This is required for the v3.5.0 release CI to succeed without crashing.
2023-02-12 23:14:07 +00:00
# NOTE: profile set to release until this rustc issue is fixed:
#
# https://github.com/rust-lang/rust/issues/107781
#
# tracked at: https://github.com/sigp/lighthouse/issues/3964
run: cargo install --path lighthouse --force --locked --features portable,gnosis --profile release
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'
Use release profile for Windows binaries (#3965) ## Proposed Changes Disable `maxperf` profile on Windows due to #3964. This is required for the v3.5.0 release CI to succeed without crashing.
2023-02-12 23:14:07 +00:00
# NOTE: profile set to release (see above)
run: cargo install --path lighthouse --force --locked --features modern,gnosis --profile release
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