fix: faster e2e runs

[ndom91]

• Follow-up from: faster E2E runs #4692
• Use debug build for test to improve build time

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
gitbutler-web	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 16, 2024 4:28pm

[Byron]

Thanks for picking this up! I gave up a little quickly there 😁.

[ndom91]

@mtsgrd what did you mean by your comment regarding gitbutler-git exactly?

[mtsgrd]

Try adding another step in test-e2e.yaml that runs cargo build -p gitbutler-git. I ran into this a few days ago, see this discord message: https://discord.com/channels/1060193121130000425/1204524097241878629/1271551056102424627

In the logs for the e2e run you see this error, albeit a bit hard to find:

*edit: let's also add RUST_BACKTRACE=1 to these e2e runs?

[ndom91]

Hmm, even with an additional cargo build -p gitbutler-git step, the Build CLI and Build Tauri (rest of application) steps don't seem to be reusing any of one anothers work.

Previously (in master), building CLI generally takes ~30s and building Tauri app takes ~4m for a total of ~4m30s. In this PR, the two/three steps still take ~4m30s in total, just split up differently.

I've passed --profile dev to each build cmd btw and also enabled the RUST_BACKTRACE=1 env var for the whole e2e workflow

[ndom91]

@mtsgrd do you want to merge this as-is? Currently there is no real gain in overall duration. The current state is approximately like this:

Before:

• Build CLI: 30s
• Build Tauri: 4m

After:

• Build gitbutler-git: 30s
• Build CLI: 2m
• Build Tauri: 2m

I'm a bit out of my depth here with Rust build tooling, so if anyone else has a good idea I'm happy to try it, but otherwise I think my time is best spent elsewhere 👍 I was hoping this would be a simple(r) change haha

[mtsgrd]

Hmm, I'd say it's better to test the release build if we don't see a big gain in performance? It's testing something closer to the thing we distribute.

[ndom91]

Hmm, I'd say it's better to test the release build if we don't see a big gain in performance? It's testing something closer to the thing we distribute.

Yeah agreed. I'll close this PR then 👍