Add build script for project foxhound.

[leeN]

Currently one of the difficulties for people to get started with project foxhound seems to be the build. As how to build foxhound with playwright is something that's currently undocumented outside of the SAP CI and my adaption of it, this seems like a big hurdle to overcome.

This PR aims to be the first step to automate most of the build requirements. It borrows heavily from Foxhound_builder, but as this script is supposed to live in tree we can simplify stuff greatly.

We can, for example, make the playwright version available in machine readable format. This avoids the issue that each user has to update the build script on each release, because we can maintain the compatible playwright version. This can be extended to cover checks for usable rustc versions in the future.

Generally, there are some additions that would be nice to have in the future:

• Support to make a commit for the version we are trying to build. This matters in combination with playwright, as we avoid having an unclean tree. It also brings some issues, as we would have to detect that we are building on top of a branch used to build playwright to avoid throwing the branch away for each build (?)

• Support to disable the preparation phase. If we want to test small changes iteratively, re-applying the playwright patches, running bootstrap etc is superfluous and can be avoided.

• Additional safeguards. Such as tests for the correct rust version. This might be cumbersome as we would have to ensure the script picks up the same rust version mach does. It seems to favor the rustup based version over the version that is installed on the main OS. This requires testing, as this is only based on my observations so far.

• Post build checks.

For example, if we compile with playwright support, we can test foxhound -juggler-pipe and if the flag is recognized, the playwright integration is available.

[tmbrbr]

Are you planning to implement the bullet points for this PR or just at some point in the future?

[leeN]

Hmm, the low hanging fruits I'd implement in this PR. The safeguards are something I'm less sure about and would leave them open for future consideration.

[tmbrbr]

That would have been my preference too!

[leeN]

Hmmm, during local testing, I get the feeling that having too many options can lead to situations where you have to recover the build environment manually.

For example, if I run bash.sh -p (build with playwright). This takes a while, and I want/need to stop the build at some point. If I want to resume the build but forget to add the -s flag (skip preparation), the script tries to apply the playwright patches again and fails (it can't apply them as they were already applied, obviously. Git apply does not seem to have the option to skip already applied changes and I'm not fully sure whether that would be safe in all cases.). Now, this all makes sense if you are familiar with Foxhound, but it might cause issues for unsuspecting users.

[tmbrbr]

I guess there will always be the issue that after applying playwright patches the user should not develop / commit on top of this. So after the build we will always want to roll-back the patches before developing anything.

Could we handle this by creating a git branch specifically where the patches are applied?

[leeN]

That was my first intuition, too; most of the building blocks for this are already in place in the script. I think this would require quite extensive documentation on how to work on Foxhound, as otherwise, people might get into states that are cumbersome to resolve.

I think the workflow that we should support based on the build script is the following:

• Changes should be developed on a checkout that does not have playwright patches applied.
• Changes must be committed before applying the playwright patches.
• To enforce the previous step, applying playwright patches fails if the current repository is dirty, i.e., has uncommitted files. This is enforced already, as otherwise, you end up with a repository where reverting the playwright patches to commit your changes becomes fiddly, especially if someone is not overly familiar with git (e.g., interactive add). This is somewhat annoying, as running tests can leave some files lying around, which you must manually remove before running the script.

What I think might work is something like the following:
In the preparation phase (i.e., this can be disabled to continue a build, e.g., after a compiler crash, which is super frequent on the box I build Foxhound on), we create a new branch and commit the playwright changes. My suggestion for the branch name is pw-build-$(date +%s), i.e., pw-build-1725959206. The Unix timestamp is not perfect, but it allows you to order them by age somewhat easily. This ensures we don't get into naming conflicts, but it requires you to clean up the stale PW branches or accumulate hundreds if you build Foxhound frequently. That seems like it is mainly an issue for folks like you and me, so this drawback seems manageable. Maybe we can add cleanup logic here, too, but this makes everything more complex, heh. I'd avoid trying to reuse branches as this seems fragile and easy to run into corner cases. We would need additional safeguards that the script is only invoked inside a playwright integration branch with specific flags, which seems manageable. There is probably some more stuff I'm forgetting, but I will take a look at the only script the Microsoft folks were using.

[leeN]

I have started updating the documentation in the Wiki and added the option to create a Git commit after applying the playwright changes (-g flag).

Due to the increasing number of flags, some combinations may be problematic, but testing them all is too time-consuming at the moment. Once our server admin is back from vacation, I'll have a look at running the build via a cron job every night to provide compiled executables to download.

[leeN]

Unless you have some change requests I think we can merge this @tmbrbr :)