andreacavalli/netty5
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
8549d7dc87
netty5/.github/workflows/ci-pr.yml

204 lines
7.6 KiB
YAML
Raw Normal View History

Add license header to our scripts and workflows (#11282) Motivation: We should have license header whenever possible. Modifications: Add header to scripts and workflow config Result: More clear licensing
2021-05-19 14:06:42 +02:00
# ----------------------------------------------------------------------------
# Copyright 2021 The Netty Project
#
# The Netty Project licenses this file to you under the Apache License,
# version 2.0 (the "License"); you may not use this file except in compliance
# with the License. You may obtain a copy of the License at:
#
# https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
# ----------------------------------------------------------------------------
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
name: Build PR
on:
pull_request:
branches: [ "master"]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
Use MAVEN_OPTS to setup timeouts for dependency downloads (#11250) Motivation: Just use MAVEN_OPTS to setup all the timeouts etc for dependency downloads. This way we at least can be sure these are applied. Modifications: - Use MAVEN_OPTS - Remove ci profile - Remove unused settings.xml file - Always use ./mvnw Result: Build stability improvements
2021-05-12 18:02:35 +02:00
env:
MAVEN_OPTS: -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.http.retryhandler.count=5 -Dmaven.wagon.httpconnectionManager.ttlSeconds=240
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
jobs:
verify-pr:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v1
with:
java-version: '11'
# Cache .m2/repository
Use the same maven cache for all (#11241) Motivation: We should use the same maven cache for all builds so we can re-use as much of the downloaded maven dependencies as possible Modifications: - Just use the same cache for all Result: Hopefully be able to re-use most of the dependencies
2021-05-11 14:07:15 +02:00
- name: Cache local Maven repository
uses: actions/cache@v2
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
with:
path: ~/.m2/repository
Correctly setup cache to be able to make use of different restore keys (#11248) Motivation: We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch Modifications: Adjust caching config to make use of different restore keys for maven caching but also docker caching Result: Better cache usage
2021-05-12 11:41:03 +02:00
key: ${{ runner.os }}-maven-verify-pr-${{ hashFiles('**/pom.xml') }}
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
restore-keys: |
Correctly setup cache to be able to make use of different restore keys (#11248) Motivation: We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch Modifications: Adjust caching config to make use of different restore keys for maven caching but also docker caching Result: Better cache usage
2021-05-12 11:41:03 +02:00
${{ runner.os }}-maven-verify-pr-
Use the same maven cache for all (#11241) Motivation: We should use the same maven cache for all builds so we can re-use as much of the downloaded maven dependencies as possible Modifications: - Just use the same cache for all Result: Hopefully be able to re-use most of the dependencies
2021-05-11 14:07:15 +02:00
${{ runner.os }}-maven-
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
- name: Verify with Maven
Make build log output less chatty (#11365) Motivation: When Maven does not run in batch mode, it will continuously print its progress as it downloads dependencies. This can produce a very large amount of log output, that makes it harder to debug build failures. Modification: Make all Maven builds run in batch mode by adding the `-B` command line flag, and have transfer progress suppressed with the `-ntp` flag. Some builds were already running batch mode but had the flag in a different location – these have had their `-B` flag moved so all builds are consistent. Result: Much less output in our build logs where Maven is just downloading stuff.
2021-06-07 10:53:10 +02:00
run: ./mvnw -B -ntp --file pom.xml verify -DskipTests=true
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
Add builds for windows (#11284) Motivation: Let's also build on windows during PR validation Modifications: Add build on windows during PR Result: Validate that all also pass on windows
2021-05-26 12:12:11 +02:00
build-pr-windows:
runs-on: windows-2016
name: windows-x86_64-java11-boringssl
needs: verify-pr
steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 11
# Cache .m2/repository
# Caching of maven dependencies
- uses: actions/cache@v2
with:
path: ~/.m2/repository
key: pr-windows-x86_64-maven-cache-${{ hashFiles('**/pom.xml') }}
restore-keys: |
pr-windows-x86_64-maven-cache-
- name: Build project
Make build log output less chatty (#11365) Motivation: When Maven does not run in batch mode, it will continuously print its progress as it downloads dependencies. This can produce a very large amount of log output, that makes it harder to debug build failures. Modification: Make all Maven builds run in batch mode by adding the `-B` command line flag, and have transfer progress suppressed with the `-ntp` flag. Some builds were already running batch mode but had the flag in a different location – these have had their `-B` flag moved so all builds are consistent. Result: Much less output in our build logs where Maven is just downloading stuff.
2021-06-07 10:53:10 +02:00
run: ./mvnw.cmd -B -ntp --file pom.xml clean package -Pboringssl -DskipHttp2Testsuite=true -DskipAutobahnTestsuite=true
Add builds for windows (#11284) Motivation: Let's also build on windows during PR validation Modifications: Add build on windows during PR Result: Validate that all also pass on windows
2021-05-26 12:12:11 +02:00
- name: Upload Test Results
if: always()
uses: actions/upload-artifact@v2
with:
name: test-results-windows-x86_64-java11-boringssl
path: '**/target/surefire-reports/TEST-*.xml'
- uses: actions/upload-artifact@v2
if: ${{ failure() }}
with:
name: build-pr-windows-target
Ensure we include hs_err* files when build failed (#11525) Motivation: We the build failed we should ensure we also include hs_err* files as it may have failed due a native crash Modifications: Adjust path matching to include hs_err as well Result: Easier to debug native crashes
2021-07-29 08:48:12 +02:00
path: |
**/target/surefire-reports/
**/hs_err*.log
Add builds for windows (#11284) Motivation: Let's also build on windows during PR validation Modifications: Add build on windows during PR Result: Validate that all also pass on windows
2021-05-26 12:12:11 +02:00
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
build-pr-aarch64:
name: linux-aarch64-verify-native
# The host should always be Linux
runs-on: ubuntu-20.04
needs: verify-pr
steps:
- uses: actions/checkout@v2
# Cache .m2/repository
Use the same maven cache for all (#11241) Motivation: We should use the same maven cache for all builds so we can re-use as much of the downloaded maven dependencies as possible Modifications: - Just use the same cache for all Result: Hopefully be able to re-use most of the dependencies
2021-05-11 14:07:15 +02:00
- name: Cache local Maven repository
uses: actions/cache@v2
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
with:
path: ~/.m2/repository
Correctly setup cache to be able to make use of different restore keys (#11248) Motivation: We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch Modifications: Adjust caching config to make use of different restore keys for maven caching but also docker caching Result: Better cache usage
2021-05-12 11:41:03 +02:00
key: ${{ runner.os }}-maven-build-pr-aarch64-${{ hashFiles('**/pom.xml') }}
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
restore-keys: |
Correctly setup cache to be able to make use of different restore keys (#11248) Motivation: We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch Modifications: Adjust caching config to make use of different restore keys for maven caching but also docker caching Result: Better cache usage
2021-05-12 11:41:03 +02:00
${{ runner.os }}-maven-build-pr-aarch64-
Use the same maven cache for all (#11241) Motivation: We should use the same maven cache for all builds so we can re-use as much of the downloaded maven dependencies as possible Modifications: - Just use the same cache for all Result: Hopefully be able to re-use most of the dependencies
2021-05-11 14:07:15 +02:00
${{ runner.os }}-maven-
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
Update run-on-arch-action (#11199) Motivation: In the past we did see problems sometime when run-on-arch-action was used. We are multiple releases behind, lets update and so maybe fix the problems. Modifications: Update to latest release Result: Use latest run-on-arch-action release
2021-04-27 13:48:51 +02:00
- uses: uraimo/run-on-arch-action@v2.0.9
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
name: Run commands
id: runcmd
with:
arch: aarch64
distro: ubuntu20.04
# Not required, but speeds up builds by storing container images in
# a GitHub package registry.
githubToken: ${{ github.token }}
# Mount the .m2/repository
dockerRunArgs: |
--volume "/home/runner/.m2/repository/:/root/.m2/repository"
# Install dependencies
install: |
apt-get update -q -y
apt-get install -q -y openjdk-11-jdk autoconf automake libtool make tar maven git
# Compile native code and the modules it depend on and run NativeLoadingTest. This is enough to ensure
# we can load the native module on aarch64
Re-enable running openssl (shared) tests on CI (#11197) Motivation: It turned out we didnt run the openssl tests on the CI when we used the non-static version of netty-tcnative. Modifications: - Upgrade netty-tcnative to fix segfault when using shared openssl - Adjust tests to only run session cache tests when openssl supports it - Fix some more tests to only depend on KeyManager if the underlying openssl version supports it Result: Run all openssl test on the CI even when shared library is used
2021-04-27 13:49:06 +02:00
#
# Use tcnative.classifier that is empty as we don't support using the shared lib version on ubuntu.
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
run: |
Make build log output less chatty (#11365) Motivation: When Maven does not run in batch mode, it will continuously print its progress as it downloads dependencies. This can produce a very large amount of log output, that makes it harder to debug build failures. Modification: Make all Maven builds run in batch mode by adding the `-B` command line flag, and have transfer progress suppressed with the `-ntp` flag. Some builds were already running batch mode but had the flag in a different location – these have had their `-B` flag moved so all builds are consistent. Result: Much less output in our build logs where Maven is just downloading stuff.
2021-06-07 10:53:10 +02:00
JAVA_HOME=/usr/lib/jvm/java-11-openjdk-arm64 ./mvnw -B -ntp -pl testsuite-native -am clean package -DskipTests=true -Dcheckstyle.skip=true -DskipNativeTestsuite=false -Dtcnative.classifier=
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
build-pr:
runs-on: ubuntu-latest
strategy:
matrix:
include:
- setup: linux-x86_64-java11
docker-compose-build: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.111.yaml build"
docker-compose-run: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.111.yaml run build-leak"
Add GraalVM to the PR build matrix (#11405) Motivation: Native image compatibility is fragile and breaks easily, so we need a PR build to tell us when this happens. Modification: Add a graalvm-based build to the PR build matrix. Result: Every PR is now also tested on Graal.
2021-06-21 16:08:40 +02:00
- setup: linux-x86_64-java11-graal
docker-compose-build: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.graalvm111.yaml build"
docker-compose-run: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.graalvm111.yaml run build-leak"
Update from JDK15 to JDK16 (#11218) Motivation: The last non-LTS release is JDK16 now. Modifications: Update from JDK15 to JDK16 for building as this is the last non-LTS release atm Result: Build with latest non-LTS release as well
2021-05-03 18:15:37 +02:00
- setup: linux-x86_64-java16
docker-compose-build: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.116.yaml build"
docker-compose-run: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.116.yaml run build-leak"
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
- setup: linux-x86_64-java11-boringssl
docker-compose-build: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.111.yaml build"
docker-compose-run: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.111.yaml run build-leak-boringssl-static"
Introduce alternative Buffer API (#11347) Motivation: In Netty 5 we wish to have a simpler, safe, future proof, and more consistent buffer API. We developed such an API in the incubating buffer repository, and taking it through multiple rounds of review and adjustments. This PR/commit bring the results of that work into the Netty 5 branch of the main Netty repository. Modifications: * `Buffer` is an interface, and all implementations are hidden behind it. There is no longer an inheritance hierarchy of abstract classes and implementations. * Reference counting is gone. After a buffer has been allocated, calling `close` on it will deallocate it. It is then up to users and integrators to ensure that the life-times of buffers are managed correctly. This is usually not a problem as buffers tend to flow through the pipeline to be released after a terminal IO operation. * Slice and duplicate methods are replaced with `split`. By removing slices, duplicate, and reference counting, there is no longer a possibility that a buffer and/or its memory can be shared and accessible through multiple routes. This solves the problem of data being accessed from multiple places in an uncoordinated way, and the problem of buffer memory being closed while being in use by some unsuspecting piece of code. Some adjustments will have to be made to other APIs, idioms, and usages, since `split` is not always a replacement for `slice` in some use cases. * The `split` has been added which allows memory to be shared among multiple buffers, but in non-overlapping regions. When the memory regions don't overlap, it will not be possible for the different buffers to interfere with each other. An internal, and completely transparent, reference counting system ensures that the backing memory is released once the last buffer view is closed. * A Send API has been introduced that can be used to enforce (in the type system) the transfer of buffer ownership. This is not expected to be used in the pipeline flow itself, but rather for other objects that wrap buffers and wish to avoid becoming "shared views" — the absence of "shared views" of memory is important for avoiding bugs in the absence of reference counting. * A new BufferAllocator API, where the choice of implementation determines factors like on-/off-heap, pooling or not. How access to the different allocators will be exposed to integrators will be decided later. Perhaps they'll be directly accessible on the `ChannelHandlerContext`. * The `PooledBufferAllocator` has been copied and modified to match the new allocator API. This includes unifying its implementation that was previously split across on-heap and off-heap. * The `PooledBufferAllocator` implementation has also been adjusted to allocate 4 MiB chunks by default, and a few changes have been made to the implementation to make a newly created, empty allocator use significantly less heap memory. * A `Resource` interface has been added, which defines the life-cycle methods and the `send` method. The `Buffer` interface extends this. * Analogues for `ByteBufHolder` has been added in the `BufferHolder` and `BufferRef` classes. * `ByteCursor` is added as a new way to iterate the data in buffers. The byte cursor API is designed to be more JIT friendly than an iterator, or the existing `ByteProcessor` interface. * `CompositeBuffer` no longer permit the same level of access to its internal components. The composite buffer enforces its ownership of its components via the `Send` API, and the components can only be individually accessed with the `forEachReadable` and `forEachWritable` methods. This keeps the API and behavioral differences between composite and non-composite buffers to a minimum. * Two implementations of the `Buffer` interface are provided with the API: One based on `ByteBuffer`, and one based on `sun.misc.Unsafe`. The `ByteBuffer` implementation is used by default. More implementations can be loaded from the classpath via service loading. The `MemorySegment` based implementation is left behind in the incubator repository. * An extensive and highly parameterised test suite has been added, to ensure that all implementations have consistent and correct behaviour, regardless of their configuration or composition. Result: We have a new buffer API that is simpler, better tested, more consistent in behaviour, and safer by design, than the existing `ByteBuf` API. The next legs of this journey will be about integrating this new API into Netty proper, and deprecate (and eventually remove) the `ByteBuf` API. This fixes #11024, #8601, #8543, #8542, #8534, #3358, and #3306.
2021-06-28 12:06:44 +02:00
- setup: linux-x86_64-java11-unsafe-buffer
docker-compose-build: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.111.yaml build"
docker-compose-run: "-f docker/docker-compose.yaml -f docker/docker-compose.centos-6.111.yaml run build-unsafe-buffer"
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
name: ${{ matrix.setup }} build
needs: verify-pr
steps:
- uses: actions/checkout@v2
# Cache .m2/repository
Use the same maven cache for all (#11241) Motivation: We should use the same maven cache for all builds so we can re-use as much of the downloaded maven dependencies as possible Modifications: - Just use the same cache for all Result: Hopefully be able to re-use most of the dependencies
2021-05-11 14:07:15 +02:00
- name: Cache local Maven repository
uses: actions/cache@v2
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
with:
path: ~/.m2/repository
Correctly setup cache to be able to make use of different restore keys (#11248) Motivation: We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch Modifications: Adjust caching config to make use of different restore keys for maven caching but also docker caching Result: Better cache usage
2021-05-12 11:41:03 +02:00
key: ${{ runner.os }}-maven-${{ matrix.setup }}-${{ hashFiles('**/pom.xml') }}
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
restore-keys: |
Correctly setup cache to be able to make use of different restore keys (#11248) Motivation: We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch Modifications: Adjust caching config to make use of different restore keys for maven caching but also docker caching Result: Better cache usage
2021-05-12 11:41:03 +02:00
${{ runner.os }}-maven-${{ matrix.setup }}-
Use the same maven cache for all (#11241) Motivation: We should use the same maven cache for all builds so we can re-use as much of the downloaded maven dependencies as possible Modifications: - Just use the same cache for all Result: Hopefully be able to re-use most of the dependencies
2021-05-11 14:07:15 +02:00
${{ runner.os }}-maven-
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
# Enable caching of Docker layers
- uses: satackey/action-docker-layer-caching@v0.0.11
continue-on-error: true
with:
Correctly setup cache to be able to make use of different restore keys (#11248) Motivation: We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch Modifications: Adjust caching config to make use of different restore keys for maven caching but also docker caching Result: Better cache usage
2021-05-12 11:41:03 +02:00
key: build-docker-cache-${{ matrix.setup }}-{hash}
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
restore-keys: |
Correctly setup cache to be able to make use of different restore keys (#11248) Motivation: We should setup the caching so it will be able to use different restore keys and so almost never need to start from scratch Modifications: Adjust caching config to make use of different restore keys for maven caching but also docker caching Result: Better cache usage
2021-05-12 11:41:03 +02:00
build-docker-cache-${{ matrix.setup }}-
build-docker-cache-
Bring forward build automation changes (#11052) This brings forward the build and release automation changes from 4.1 (#10879, #10883, #10884, #10886, #10888, #10889, #10893, #10900, #10933, #10945, #10966, #10968, #11002, and #11019) to 5.0. Details are as follows: * Use Github workflows for CI (#10879) Motivation: We should just use GitHub Actions for the CI Modifications: - Adjust docker / docker compose files - Add different workflows and jobs to deploy and build the project Result: Don't depend on external CI services * Fix non leak build condition * Only use build and deploy workflows for 4.1 for now * Add deploy job for cross compiled aarch64 (#10883) Motivation: We should also deploy snapshots for our cross compiled native jars. Modifications: - Add job and docker files for deploying cross compiled native jars - Ensure we map the maven cache into our docker containers Result: Deploy aarch64 jars and re-use cache * Use correct docker-compose file to deploy cross compiled artifacts * Use correct docker-compose task to deploy for cross compiled artifacts * Split pr and normal build (#10884) Motivation: We should better use seperate workflows for PR and normal builds Modifications: - Split workflows - Better cache reuse Result: Cleanup * Only deploy snapshots for one arch Motivation: We need to find a way to deploy SNAPSHOTS for different arch with the same timestamp. Otherwise it will cause problems. See https://github.com/netty/netty/issues/10887 Modification: Skip all other deploys then x86_64 Result: Users are able to use SNAPSHOTS for x86_6 * Use maven cachen when running analyze job (#10888) Motivation: To prevent failures to problems while downloading dependencies we shoud cache these Modifications: Add maven cache Result: No more failures due problems while downloading dependencies * Also include one PR job that uses boringssl (#10886) Motivation: When validating PRs we should also at least run one job that uses boringssl Modifications: - Add job that uses boringssl - Cleanup docker compose files - Fix buffer leak in test Result: Also run with boringssl when PRs are validated * Use matrix for job configurations (#10889) Motivation: We can use the matrix feature to define our jobs. This reduces a lot of config Modification: Use job matrix Result: Easier to maintain * Correctly deploy artifacts that are build on different archs (#10893) Motivation: We need to take special care when deploying snapshots as we need to generate the jars in multiple steps Modifications: - Use the nexus staging pluging to stage jars locally in multiple steps - Add extra job that will merge these staged jars and deploy these Result: Fixes https://github.com/netty/netty/issues/10887 * Dont use cron for PRs Motivation: It doesnt make sense to use cron for PRs Modifications: Remove cron config Result: Cleanup * We run all combinations when validate the PR, let's just use one type for normal push Motivation: Let us just only use one build config when building the 4.1 branch. Modifications: As we already do a full validation when doing the PR builds we can just only use one build config for pushes to the "main" branches Result: Faster build times * Update action-docker-layer-caching (#10900) Motivation: We are three releases behind. Modifications: Update to latest version Result: Use up-to-date action-docker-layer-caching version * Verify we can load native modules and add job that verifies on aarch64 as well (#10933) Motivation: As shown in the past we need to verify we actually can load the native as otherwise we may introduce regressions. Modifications: - Add new maven module which tests loading of native modules - Add job that will also test loading on aarch64 Result: Less likely to introduce regressions related to loading native code in the future * Let script fail if one command fail (#10945) Motivation: We should use `set -e` to ensure we fail the script if one command fails. Modifications: Add set -e to script Result: Fail fast * Use action to report unit test errors (#10966) Motivation: To make it easier to understand why the build fails lets use an action that will report which unit test failed Modifications: - Replace custom script with action-surefire-report Result: Easier to understand test failures * Use custom script to check for build failures (#10968) Motivation: It turns out we can't use the action to check for build failures as it can't be used when a PR is done from a fork. Let's just use our simple script. Modifications: - Replace action with custom script Result: Builds for PRs that are done via forks work again. * Publish test results after PR run (#11002) Motivation: To make it easier to understand why a build failed let us publish the rest results Modifications: Use a new workflow to be able to publish the test reports Result: Easier to understand why a PR did fail * Fix test reports name * Add workflow to cut releases (#11019) Motivation: Doing releases manually is error-prone, it would be better if we could do it via a workflow Modification: - Add workflow to cut releases - Add related scripts Result: Be able to easily cut a release via a workflow * Update build for master branch Motivation: The build changes were brought forward from 4.1, and contain many things specific to 4.1. Modification: Changed baseline Java version from 8 to 11, and changed branch references from "4.1" to "master". Result: Builds should now work for the master branch. Co-authored-by: Norman Maurer <norman_maurer@apple.com>
2021-03-02 17:44:03 +01:00
- name: Build docker image
run: docker-compose ${{ matrix.docker-compose-build }}
- name: Build project with leak detection
run: docker-compose ${{ matrix.docker-compose-run }} | tee build-leak.output
- name: Checking for test failures
run: ./.github/scripts/check_build_result.sh build-leak.output
- name: Checking for detected leak
run: ./.github/scripts/check_leak.sh build-leak.output
- name: Upload Test Results
if: always()
uses: actions/upload-artifact@v2
with:
name: test-results-${{ matrix.setup }}
path: '**/target/surefire-reports/TEST-*.xml'
- uses: actions/upload-artifact@v2
if: ${{ failure() }}
with:
name: build-${{ matrix.setup }}-target
Ensure we include hs_err* files when build failed (#11525) Motivation: We the build failed we should ensure we also include hs_err* files as it may have failed due a native crash Modifications: Adjust path matching to include hs_err as well Result: Easier to debug native crashes
2021-07-29 08:48:12 +02:00
path: |
**/target/surefire-reports/
**/hs_err*.log
Reference in New Issue Copy Permalink