Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance history canary #1209

Merged
merged 11 commits into from
Oct 21, 2024
85 changes: 62 additions & 23 deletions .github/workflows/perf-regression-ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -97,45 +97,81 @@ jobs:
openjdk-perf-regression:
runs-on: [self-hosted, Linux, freq-scaling-off]
timeout-minutes: 1440
env:
# This version will be used as the canary version, and will be used to checkout both
qinsoon marked this conversation as resolved.
Show resolved Hide resolved
# `mmtk-core` and `mmtk-openjdk`.
#
# A "canary" is a chosen version that is tested alongside each merged pull request. The
# performance of the canary should not change unless
#
# 1. There is an environment change, such as changes of the operating system, the hardware,
# the firmware, or the methodology we use for testing, or
# 2. There are non-deterministic factors (i.e. noises) affecting each execution.
#
# Running the canary alongside regular regression tests help us identify unnoticed environment
# changes and the level of noise.
#
# Currently, we choose one release version as the canary, and will use it until we can no
# longer run it for any reason, such as the toolchain for compiling that version is no longer
# available. Then we may change to another release version and mark the change of canary on
# the timeline, or introduce a mechanism to dynamically choose the canary version.
CANARY_VERSION: "v0.28.0"
steps:
- name: Checkout MMTk Core
# checkout latest versions
- name: Checkout MMTk Core (latest)
uses: actions/checkout@v4
with:
path: mmtk-core
- name: Checkout OpenJDK Binding
path: latest/mmtk-core
- name: Checkout OpenJDK Binding (latest)
uses: actions/checkout@v4
with:
repository: mmtk/mmtk-openjdk
path: mmtk-openjdk
- name: Checkout OpenJDK
working-directory: mmtk-openjdk
path: latest/mmtk-openjdk
- name: Checkout OpenJDK (latest)
working-directory: latest/mmtk-openjdk
run: |
./.github/scripts/ci-checkout.sh
# checkout perf-kit
- name: Checkout Perf Kit
uses: actions/checkout@v4
with:
repository: mmtk/ci-perf-kit
ref: "0.8.0"
ref: "0.8.1"
path: ci-perf-kit
token: ${{ secrets.CI_ACCESS_TOKEN }}
submodules: true
# setup
- name: Overwrite MMTk core in openjdk binding
run: cp -r mmtk-core mmtk-openjdk/repos/
- name: Setup Rust Toolchain
run: echo "RUSTUP_TOOLCHAIN=`cat mmtk-core/rust-toolchain`" >> $GITHUB_ENV
# cleanup previosu build
- name: Cleanup previous build
# checkout canary versions.
- name: Checkout MMTk Core (canary)
uses: actions/checkout@v4
with:
ref: ${{ env.CANARY_VERSION }}
path: canary/mmtk-core
- name: Checkout OpenJDK Binding (canary)
uses: actions/checkout@v4
with:
ref: ${{ env.CANARY_VERSION }}
repository: mmtk/mmtk-openjdk
path: canary/mmtk-openjdk
- name: Checkout OpenJDK (canary)
working-directory: canary/mmtk-openjdk
run: |
rm -rf mmtk-openjdk/repos/openjdk/scratch
rm -rf mmtk-openjdk/repos/openjdk/build
- name: Setup
./.github/scripts/ci-checkout.sh
# setup
- name: Setup directory structures
run: |
./ci-perf-kit/scripts/history-run-setup.sh
sed -i 's/^mmtk[[:space:]]=/#ci:mmtk=/g' mmtk-openjdk/mmtk/Cargo.toml
sed -i 's/^#[[:space:]]mmtk/mmtk/g' mmtk-openjdk/mmtk/Cargo.toml
- id: branch
for BASE_DIR in ./latest ./canary; do
pushd $BASE_DIR
# replace dependency
# Note that ci-replace-mmtk-dep.sh will apply `realpath()` to the `--mmtk-core-path` option.
# so we specify the relative path from the PWD to the mmtk-core repo.
./mmtk-core/.github/scripts/ci-replace-mmtk-dep.sh mmtk-openjdk/mmtk/Cargo.toml \
--mmtk-core-path mmtk-core
# cleanup previous build
rm -rf mmtk-openjdk/repos/openjdk/scratch
rm -rf mmtk-openjdk/repos/openjdk/build
popd
done
- name: Setup branch name
id: branch
# we cannot use env vars in action input (the deploy step). So put the env var to this step's outputs.
run: echo "branch_name=$(echo ${GITHUB_REF#refs/heads/} | sed 's/\//_/g')" >> $GITHUB_OUTPUT
# run
Expand All @@ -145,7 +181,10 @@ jobs:
export RESULT_REPO_BRANCH=${{ env.RESULT_REPO_BRANCH }}
export RESULT_REPO_ACCESS_TOKEN=${{ secrets.CI_ACCESS_TOKEN }}
export FROM_DATE=2020-07-10
./ci-perf-kit/scripts/openjdk-history-run.sh ./mmtk-openjdk ./reports/${{ steps.branch.outputs.branch_name }}
./ci-perf-kit/scripts/openjdk-history-run.sh \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be easier to implement if we do two separate runs, one for the commit, one for the canary version, and then plot them in two separate graphs. In that case, the code for plotting the original graph does not need big changes, and can be used to plot the canary graph.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I saw mmtk/ci-perf-kit#47. You are doing that in ci-perf-kit. That's fine.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qinsoon The main concern is that ./ci-perf-kit/scripts/openjdk-history-run.sh also commits to the mmtk/ci-perf-result repo and generates the HTML. It is safer to use one single bash script to test both the newest version and the canary.

./latest/mmtk-openjdk \
./canary/mmtk-openjdk \
./reports/${{ steps.branch.outputs.branch_name }}
# deploy
- name: Deploy to Github Page
if: ${{ env.DEPLOY == 'true' }}
Expand Down
Loading