Add working directory to build plugin action, enable yarn 4

[SandersAaronD]

This does the following:

1. Adds a working directory option to the build plugin option, which allows building plugins not in the root. By default this is project root; any project currently using the action will not change.

2. Enables corepack, which lets projects using yarn 4 build. Core grafana is using yarn 4, and this seems to provide a better match for dependency resolution behavior.

[CLAassistant]

All committers have signed the CLA.

[SandersAaronD]

Clean build here: https://github.com/SandersAaronD/ai-training-o11y/actions/runs/9741065258

[academo]

I have tested this PR and I can see it working in both the cases when a subdirectory is passed and when is not, so nothing is breaking.

But I am not confident this is the direction we should take to address mono repos with a plugin (or multiple plugins) inside. I understand in your case you have your whole plugin setup isolated in a subfolder but it is not really a "mono repo" setup with namespaces as normally a mono repo would be.

The current status of the PR will solve this very specific scenario but not the normal mono-repo case.

About adding corepack to the action. Corepack is still an experimental API and might be removed from nodejs in the future (even in a minor version release). We also don't have enough information how adding this will affect people using the action already. I prefer we keep this action as stable as possible without experimental apis.

Regarding your particular problem, perhaps you should consider setting working-directory as a run default in your workflow where you call the build-action?

[SandersAaronD]

Because I did need this to run for me on a short timeline, I ended up copying the action code into my repo so that I can modify it. I am not especially worried about this PR in particular, especially the part around handling Yarn which is legitimately tricky and odd.

Backing up, from a much higher-level view, I have consistently had basically these requirements:

1. I have an arbitrary plugin, possibly freshly initialized with "yarn create @grafana/plugin"
2. It runs yarn when some build tools assume it runs npm
3. I have moved it into a subdirectory, when most build tools assume that plugins are in root
4. I have a golang build that generates large binaries, and existing tools in actions (including this action) only create and sign one .zip file instead of several that are platform-specific

What I'd want is a reusable action which can be upstreamed and maintained that supports

1. Building plugins that build with either yarn or npm
2. Building plugins located in subdirectories
3. Building and signing platform-specific .zip files for cases where there are large golang binaries

I don't see a path to upstreaming anything that accomplishes this. Things like setting the working directory in an action that was written for a plugin in root have not worked for me because usually at least one step of the action assumes in some way that the plugin is in root (e.g., the golang setup step will fail to cache dependencies and make builds very slow if your plugin is not in root).

I have sort of a bad workflow that accomplishes this on one plugin. The plugin build I was looking at this for currently works but doesn't do 3), the building and signing platform-specific zip files, and I will probably try to reimplement that in a way that is less bad. However, once I have that it's not clear that it can be reusable even in principle because if it's the build for a specific plugin no other plugin would be able to reasonably expect that it would be maintained for other plugins.

If there were a path to upstreaming an action that did meet team requirements for building plugins with backends, that would seem like it would reduce work much more in the long run.