Bugzilla

(In reply to Markus Stange [:mstange] from comment #4)
> We could store the output on npm, either by manually doing a new release of symbolicator-cli every time we do a deploy, or by adding a github CI job which does a release whenever we merge into the deploy branch.
> Or we could have a toolchain job in Firefox CI which pulls the profiler repo, does the build, and outputs the compiled symbolicator-cli as an artifact.

Having a pre-built release that we could pull would make it's usage mostly trivial, and it could become a fetch task instead of a toolchain. Although a toolchain might be preferred if we ever need anything special for Mozilla-related tasks.

> Where should the build step be performed, and where should the output ("compiled symbolicator-cli") be stored?

We can do the same thing as browsertime where we install directly to the same folder that the mach_commands.py (or install scripts exist in) and add them to the .gitignore/.hgignore files. Alternatively, you can always install to a `~/.mozbuild` subfolder.

(In reply to Markus Stange [:mstange] from comment #5)
> `./mach browsertime` seems [use `setup_helper` from tools/lint/eslint](https://searchfox.org/mozilla-central/rev/fdb34ddfe30bd54aba991feb72b1476c77938e46/tools/browsertime/mach_commands.py#283-284,356-362) to perform the actual `npm install` of the package.json dependencies .
> 
> So maybe that's all we need?
> 
> - Have a new directory to host the `package.json` with the dependency on the built symbolicator-cli script, for example at `testing/mozbase/mozgeckoprofiler/mozgeckoprofiler/symbolicator-cli/package.json`
> - In mozbase ProfilerSymbolicator, call setup_helper's `package_setup` function if needed
> - In mozbase ProfilerSymbolicator, invoke the installed symbolicator-cli script
> 
> Does that sound reasonable?

Yup, that sounds reasonable to me. It's unclear to me though why we can't call `setup_helper.package_setup` in a toolchain and then pull in the artifact of that setup to our CI tasks? That would save a lot of CI time even if it's platform specific. Maybe I'm misunderstanding what you're considering here. I think for local runs, it makes sense to have something in (or near) `mozgeckoprofiler` to handle the installs.

> The "if needed" above does some heavy lifting - how should we detect whether we need to re-run npm install? Ah, `setup_helper` seems to use `npm ci` if no force update is requested, but I think it'll still emit a bunch of logging every time.

That shouldn't be difficult. We do this for detecting when to update the browsertime package, and it's been working without issue for a while now: https://searchfox.org/mozilla-central/source/testing/raptor/mach_commands.py#194-201

(In reply to Markus Stange [:mstange] from comment #4)
> We could store the output on npm, either by manually doing a new release of symbolicator-cli every time we do a deploy, or by adding a github CI job which does a release whenever we merge into the deploy branch.
> Or we could have a toolchain job in Firefox CI which pulls the profiler repo, does the build, and outputs the compiled symbolicator-cli as an artifact.

Having a pre-built release that we could pull would make its usage mostly trivial, and it could become a fetch task instead of a toolchain. Although a toolchain might be preferred if we ever need anything special for Mozilla-related tasks.

> Where should the build step be performed, and where should the output ("compiled symbolicator-cli") be stored?

We can do the same thing as browsertime where we install directly to the same folder that the mach_commands.py (or install scripts exist in) and add them to the .gitignore/.hgignore files. Alternatively, you can always install to a `~/.mozbuild` subfolder.

(In reply to Markus Stange [:mstange] from comment #5)
> `./mach browsertime` seems [use `setup_helper` from tools/lint/eslint](https://searchfox.org/mozilla-central/rev/fdb34ddfe30bd54aba991feb72b1476c77938e46/tools/browsertime/mach_commands.py#283-284,356-362) to perform the actual `npm install` of the package.json dependencies .
> 
> So maybe that's all we need?
> 
> - Have a new directory to host the `package.json` with the dependency on the built symbolicator-cli script, for example at `testing/mozbase/mozgeckoprofiler/mozgeckoprofiler/symbolicator-cli/package.json`
> - In mozbase ProfilerSymbolicator, call setup_helper's `package_setup` function if needed
> - In mozbase ProfilerSymbolicator, invoke the installed symbolicator-cli script
> 
> Does that sound reasonable?

Yup, that sounds reasonable to me. It's unclear to me though why we can't call `setup_helper.package_setup` in a toolchain and then pull in the artifact of that setup to our CI tasks? That would save a lot of CI time even if it's platform specific. Maybe I'm misunderstanding what you're considering here. I think for local runs, it makes sense to have something in (or near) `mozgeckoprofiler` to handle the installs.

> The "if needed" above does some heavy lifting - how should we detect whether we need to re-run npm install? Ah, `setup_helper` seems to use `npm ci` if no force update is requested, but I think it'll still emit a bunch of logging every time.

That shouldn't be difficult. We do this for detecting when to update the browsertime package, and it's been working without issue for a while now: https://searchfox.org/mozilla-central/source/testing/raptor/mach_commands.py#194-201