build-godot hangs forever

[jdbecker]

I'd love to know if I'm the only one having this issue: when I try to use the build-godot action via the step:

- name: Build and upload artifacts for all platforms
  uses: CapsCollective/godot-actions/build-godot@v1.0
  with:
    godot-executable: ${{ steps.install-godot.outputs.godot-executable }}

I am finding that it hangs indefinitely. I've tried checking out some of your other projects to see if you are getting this to work and maybe I'm just doing something wrong. The newest Godot project at CapsCollective's public repos seems to be sunflower so I tried copying this workflow almost exactly and found my workflow would hang when I ran it at this point: https://github.com/CapsCollective/sunflower/blob/develop/.github/workflows/verify-develop.yml#L58

I'm not really sure how to debug this because I'm not getting hardly any output, and when I try to reproduce locally, it finishes successfully.

Any help appreciated!

[jonjondev]

When you say that it runs forever, how long was it running for exactly, and did you kill the process or did Github? It would be useful if you could link me to the workflow run and repo.

[jdbecker]

The longest I ever let it run for before giving up and assuming it was never going to work is this one:
https://github.com/jdbecker/They-Comin/actions/runs/8954994091

[jdbecker]

Oh I guess in this case I was just doing the editor "re-import" step, but the symptom is the same

[jdbecker]

Here's an example that's hanging on the build action itself: https://github.com/jdbecker/They-Comin/actions/runs/8956219984/job/24597795856

[jdbecker]

It seems maybe to have something to do with the Godot CLI itself, since my re-import step was also hanging. You never saw anything like this when you were setting up your projects? That suggests to me that the issue is something about my project itself, but I can't imagine what, and the error output is not helpful... 🤔

[jdbecker]

For a bit I thought maybe it was because I had blender files in my project and the container running the build would not have had access to blender, but I removed the blend files and replaced them with the exported gltf files and had the same result - the only difference being that I didn't get an error about blender not being found.

[jonjondev]

So 50 mins is not an absurd amount of time for a project with a large amount of assets on a Github runner, given the amount of process they have. That being said, I opened up your project on macOS and had to wait about 10 minutes on my fairly speedy machine. Something about your project is configured in such a way that there are a ton of load errors that are likely slowing down the import time on macOS (which the action is using) - probably including the attempted Blender auto importing. That would be my guess anyway.

[jdbecker]

That's very strange. When I run it locally on Windows 10, the action completes in seconds. I could try switching the runner to a Windows runner though, thanks for the tip!

[jonjondev]

Let me know what you find in that regard. We've been working with a macOS build runner for quite a while because it tends to provide the best simulation of our working environment. Keep in mind that whatever OS you use as a runner, you will need to install Blender as a dependency for the importer to function correctly.

[jdbecker]

Well I removed all the blend files specifically so that wouldn't be the case

[jdbecker]

Hmm, I haven't run it in a week or so, but I just tried running it again after making a few changes and now Godot won't even install using your install-godot action

mv: cannot create directory '/Applications/Godot.app': No such file or directory

see the full context here: https://github.com/jdbecker/They-Comin/actions/runs/9080402847/job/24951874417

[jdbecker]

Maybe this is because I changed to the Windows runner?

[jdbecker]

So I was able to get access to a macbook myself, and I had to download the windows build template, but after doing so, the project built for me in only about 30 seconds. Ugh, I wish this CLI gave better output on what it was doing when it just stops for an hour.

[PeterHindes]

The reimport step has no --quit flag like it does in the examples on the blog

Could that be what is causing it to just stay there? Also do we really need the reimport step if we recommend doing it in the calling action already.

[jonjondev]

The reimport step has no --quit flag like it does in the examples on the blog

A later version of Godot, ended up adding the --import option which "implies --editor and --quit" as detailed here.

Could that be what is causing it to just stay there? Also do we really need the reimport step if we recommend doing it in the calling action already.

You're right that it may be redundant at this point, but from memory, I added it on both ends to verify that the import step had completed successfully the first time as it wouldn't catch all script classes in the class DB.