Skip to content

Fixed various benchmark issues#935

Merged
Perryvw merged 11 commits intoTypeScriptToLua:masterfrom
lolleko:benchmark-fixes
Nov 23, 2020
Merged

Fixed various benchmark issues#935
Perryvw merged 11 commits intoTypeScriptToLua:masterfrom
lolleko:benchmark-fixes

Conversation

@lolleko
Copy link
Copy Markdown
Member

@lolleko lolleko commented Nov 5, 2020

Benchmarks now work for pull requests from a fork (at least partially see comment: #935 (comment))
Fixed comparison info not being emitted correctly after #878
Bump actions/github-script from 0.9.0 to v3
Moved create benchmark check script to standalone js file

Benchmarks now hopefully work for pull requests from a fork
Fixed comparison info not beeing emmitted correctly after TypeScriptToLua#878
Bump actions/github-script from 0.9.0 to v3
Moved create benchmark check script to standalone js file
@lolleko lolleko marked this pull request as draft November 5, 2020 12:24
const create_benchmark_check = require(`${process.env.GITHUB_WORKSPACE}/commit/.github/scripts/create_benchmark_check.js`);
return create_benchmark_check({github, context, core});
- name: Benchmark results
run: echo "${{steps.script-combine-results.outputs.result}}" | glow -s dark -w 120 -
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do we even need markdown as an intermediary encoding here? Would changing Lua to output a regular string with ANSI codes require too much changes?

Copy link
Copy Markdown
Member Author

@lolleko lolleko Nov 7, 2020

Choose a reason for hiding this comment

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

Definitely possible without markdown. But I think the tables would be quite a bit of work. Also terminal color handling is often different across platforms and emulators, I am not sure how much of an issue that is, but that might require some additional work.

@@ -1,8 +1,11622 @@
{
"name": "typescript-to-lua",
"version": "0.36.0",
"lockfileVersion": 1,
"lockfileVersion": 2,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

FWIW that would mean that every contributor would have to use Node >=15, otherwise npm v6 would revert these lockfile changes. But not upgrading also isn't great, since then some contributors would have to rollback node. Alternatively we can wait for corepack to land, and lock npm to v6 even on newer node versions.

Copy link
Copy Markdown
Member Author

@lolleko lolleko Nov 7, 2020

Choose a reason for hiding this comment

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

Yeah I wasn't sure what to do about this one. I have a new system and therefore have a fresh install of node.

The changelog mentions that the new lockfile version is backwards compatible, but I have not been able to try it:

https://blog.npmjs.org/post/626173315965468672/npm-v7-series-beta-release-and-semver-major

package-lock.json is updated to a newer format, using "lockfileVersion": 2. This format is backwards-compatible with npm CLI versions using "lockfileVersion": 1, but older npm clients will print a warning about the version mismatch.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Running npm install on v6 downgrades lockfile back to "lockfileVersion": 1 and removes new key, which I wouldn't really call backwards compatible. But I guess that's okay

@lolleko
Copy link
Copy Markdown
Member Author

lolleko commented Nov 7, 2020

TL;DR Tried to use a new GitHub feature to allow the benchmark check to be posted for fork PRs. But I had security concerns so instead the benchmark results are just emitted to the action log.


My initial idea was to use GitHub actions new on: pull_request_target (https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/).

With pull_request_target an actions runner for a fork PR gets read/write GITHUB_TOKEN.
This would allow us to use github.checks.create in workflows triggered by a PR.
To make sure no modified (malicious) workflows are executed with a read/write token, the runner uses the workflows from the upstream's master branch:

instead of running against the workflow and code from the merge commit, the event runs against the workflow and code from the base of the pull request. This means the workflow is running from a trusted source and is given access to a read/write token as well as secrets enabling the maintainer to safely comment on or label a pull request.

So why not use pull_request_target?
The problem is that we execute arbitrary Lua code from the PR commit during benchmarking. If an attacker is able to break out from the LuaVM he could potentially get access to a read/write token for this repo. That is not good, obviously...

I am summarizing my thought process here, as a reference in case anyone thinks about using pull_request_target in the future.
pull_request_target should not be used for any workflow that execute arbitrary code, for example benchmarks or tests.

Instead the benchmark results are only posted to the log and no check is created.

Co-authored-by: ark120202 <ark120202@gmail.com>
@lolleko lolleko marked this pull request as ready for review November 13, 2020 13:53
@Perryvw Perryvw merged commit 54569aa into TypeScriptToLua:master Nov 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants