Add github app and metadata to benchmark json. #6
Conversation
pipeline.ml
Outdated
| | Some i -> [ "--cpuset-cpus"; string_of_int i ] | ||
| | None -> [] | ||
| in | ||
| let docker_cpuset_mems = |
There was a problem hiding this comment.
Would it be possible to leave these helper functions one level up? They don't seem to change the value in each iteration and would make it a bit easier to see what's new
There was a problem hiding this comment.
It looks as though this PR gives up the ability of running the benchmarks independently of a GitHub webhook trigger / App configuration and such. Personally, I find it useful to work independently of that API when making changes to the pipeline and testing (this was the motivation behind PRs #3 and #4).
If you think it's not worth maintaining this code purely for testing purposes, that's OK. Otherwise, we can look at using Cmdliner subcommands (or required options) to allow toggling the input mode at runtime.
pipeline.ml
Outdated
| let res = hash ^ owner ^ name in | ||
| res |
There was a problem hiding this comment.
Same as just having hash ^ owner ^ name as the last line, but fine if you're deliberately naming it.
pipeline.ml
Outdated
| @@ copy ~src:[ "--chown=opam:opam ." ] ~dst:"index" () | ||
| @@ workdir "index" | ||
| @@ run "ls" |
There was a problem hiding this comment.
Are these lss in here for debugging purposes?
Earlier the pipeline monitored only one branch, and one repository at a time. This allows the pipeline to monitor multiple branches and will be triggered everytime a new PR is created.
gs0510
force-pushed
the
add_pr_trigger
branch
from
d7ef345
to
07d9c2b
Compare
@craigfe |
|
Both versions of the pipeline at some point depend on a We would then split the runtime API into two endpoints, consuming Finally, change the |
No description provided.