Some of our CI scripts, e.g. performance-regression-ci.yml, use the ${{ secrets.CI_ACCESS_TOKEN }} for things that don't need such a high privilege.
For example, performance-regression-ci.yml uses the secret to download the canary release of OpenJDK. But the release is publicly accessible.
As another example, in the "Performance Run" steps (for OpenJDK and JikesRVM alike), The secret token is used to get historical data from the non-public ci-perf-results repository. The main reason for this is to aggregate and plot all results in the history to make a web page suitable for uploading. But running the benchmark doesn't need
As a principle, GitHub workflows should be granted minimal privilege for them to do their jobs.
For downloading the canary, we could just download it using the URL https://github.com/mmtk/mmtk-openjdk/releases/download/v0.28.0/jdk-11.0.19-internal+0_linux-x64_bin.tar.gz, without any GitHub privilege.
We can refactor the performance run and the plotting and uploading.
- The performance run only runs the benchmarks and produce results.
- A subsequent plotting job will use the privilege to clone the
ci-perf-result repo, aggregate the results, commit and push the updated history, and generate web pages that include the plots.
- A subsequent deploying job will use the privilege to deploy the web pages.
Note that if we are only testing the performance runs, we may skip the plotting and deploying steps. In this case, the workflow will not need any secret at all.
For other jobs, we could use the ${{ github.token }} or equivalently ${{ secrets.GITHUB_TOKEN }}, and control the permissions using the permissions workflow syntax.
Some of our CI scripts, e.g.
performance-regression-ci.yml, use the${{ secrets.CI_ACCESS_TOKEN }}for things that don't need such a high privilege.For example,
performance-regression-ci.ymluses the secret to download the canary release of OpenJDK. But the release is publicly accessible.As another example, in the "Performance Run" steps (for OpenJDK and JikesRVM alike), The secret token is used to get historical data from the non-public ci-perf-results repository. The main reason for this is to aggregate and plot all results in the history to make a web page suitable for uploading. But running the benchmark doesn't need
As a principle, GitHub workflows should be granted minimal privilege for them to do their jobs.
For downloading the canary, we could just download it using the URL https://github.com/mmtk/mmtk-openjdk/releases/download/v0.28.0/jdk-11.0.19-internal+0_linux-x64_bin.tar.gz, without any GitHub privilege.
We can refactor the performance run and the plotting and uploading.
ci-perf-resultrepo, aggregate the results, commit and push the updated history, and generate web pages that include the plots.Note that if we are only testing the performance runs, we may skip the plotting and deploying steps. In this case, the workflow will not need any secret at all.
For other jobs, we could use the
${{ github.token }}or equivalently${{ secrets.GITHUB_TOKEN }}, and control the permissions using thepermissionsworkflow syntax.