Closed NathanWarden closed 6 years ago
vnen
commented
6 years ago This is normal because the import system is part of the editor and won't be available in a non-tools build. This could be solved by something like #533, though re-purposed for the Godot 3 import system (i.e. make the import process available from the command line).
NathanWarden
commented
6 years ago I suppose that makes sense. It should probably have a flag to force the re-import then:
For instance:
godot -i path/to/scene
brainsick
commented
6 years ago I'm not entirely clear on the use case here. If you're trying to run this example scene then your CI/automation environment has working 3D support and is capable of running the full tools build, yes?
Given that, working with what Godot provides today, a creative solution (read: hack) would be to simply prime the pump:
cd $PROJECT_PATH
$BIN/godot -e project.godot & sleep 10 && kill $!
$BIN/godot Node.tscnThis assumes that your assets will take 10 seconds to import; that's more than sufficient for this scene. This assumes that your scene will quit of its own accord.
If you don't like the timed aspect of this, you could enforce a project.godot that ensures a main scene that quit()s itself. Then the import can take however long it takes although you'll still want some kind of watchdog in an automation environment.
NathanWarden
commented
6 years ago @brainsick Thanks for the advice. I don't personally need it to function right now (although the sooner the better), this issue is just to point out that it is needed for the long term. We definitely need something headless that we can use for CI/testing that isn't hacky. Even if it were something like "godot -i -q" for "import and quit" would be fine. Having it sleep for an arbitrary amount of time might be fine in some cases (or having an auto-quit somehow built into the main scene), but in the long term these are hacks and not proper long term solutions. Again, just to be clear, this issue isn't to solve an immediate problem, although I'd like to setup CI/testing sooner rather than later, but rather serves as a reminder that this needs to be implemented in order for CI to work properly and not in a hacky way.
Even if we had to do something multi-step like the following pseudo-bash-script would be fine too:
cd /path/to/project
godot -i -q
godot -export "Linux X11 Server" ./builds/project.x86_64 # Did the project build successfully?
./builds/project.x86_64 # This could run testsSpecifically in response to the "sooner the better" part, I think it's possible to have a reasonably sound implementation of this, today. The workflow is repeatable and scriptable.
I agree that timing the import is insanely hacky. That's on the discard pile. I agree that editing an existing project's project.godot to quit() is hacky. That's on the discard pile.
I'm inclined to call the main_scene / tool / quit() workflow as clever, not necessarily a hack. It works for this sample project. It's worth testing on a larger project.
It would then be possible to simply add an import.project.godot and TheQuitter.tscn to your existing project.
NathanWarden
commented
6 years ago @brainsick Thanks for the detailed setup. If I start needing testing and CI before this is fixed I will likely adapt your solution for my needs... thanks again :)
brainsick
commented
6 years ago I was perusing the source and happened upon override.cfg. Replacing import.project.godot with override.cfg.off seems slightly less hacky; it's one less file operation anyway.
I think the only remaining hacky aspect of this is that you have a scene that you don't want people to click on.
You could hide that in a .hidden directory with a .gdignore! It works; it doesn't show up in the Editor. It still shuts down Godot when "force" loaded as the main scene.
So, Godot starts up, imports, and shuts down cleanly. It's three files that can co-exist with an existing project. The user danger is mitigated by hiding TheQuitter. Looks viable. :)
I tried it on godot-sponza which is one of the larger projects I have access to.
NathanWarden
commented
6 years ago Thanks for the help, I ended up adapting your solution, but without needing to copy anything. What I did is:
RunTests.sh
#!/bin/bash
GODOT="/home/nathan/Projects/OpenSource/godot/bin/godot.x11.tools.64.mono"
$GODOT -e AutoQuit.tscn &
PID="$!"
while [[ ! -f imported ]]
do
sleep 1
done
rm imported
sleep 5
kill $PID
$GODOT Spatial.tscnAutoQuit.gd
tool
extends Node
var filepath = "res://imported"
func _ready():
write_file()
get_tree().quit()
func write_file():
var savefile = File.new()
var result = savefile.open(filepath,File.WRITE)
print(result)
savefile.store_line("imported")
savefile.close()Ah, I wouldn't have suspected that editing TheQuitter.tscn directly would have resulted in a whole project scan / import. But indeed it does; even when in a sub directory. That eliminates the override swapping and simplifies things even further.
That's one file addition that can optionally be hidden from Editor view completely and one import command.
So, glad you found a solution that works for you. I'll stop updating with new developments as I basically consider this solved.
On to the next quest/issue. :)
mhilbrunner
commented
6 years ago I'll stop updating with new developments as I basically consider this solved.
I'll close this then :)
Godot version:
Current head as of Jan 21, 2018: 37cb029fcc158b8dc43bfefecc6709ae0237642b
OS/device including version:
Linux (but probably affects all OSes)
Issue description:
Opening a project via command line that has never been imported throws "Failed loading resource" errors. This makes it impossible to deploy Godot projects within CI, automated testing and/or automated build systems.
Steps to reproduce: 1) Delete the ".import" folder (if one exists) 2) Open a project via the terminal such as "godot scene.tscn" 3) Godot quits with errors.
Minimal reproduction project:
ExampleProject.zip