Reconnecting RemoteRequirement

[seba--]

1. Remote requirements must be installed by a builder before it tries to establish a remote connection.
2. When the initial build run failed because the machine was offline, a subsequent build must be executed if the machine is online now. The remote requirement should make sure of this behavior.

[seba--]

Concrete example:

1. [offline] Use git remote synchronizer to clone a repository (fails)
2. [online] Reexecute build (still fails, but should succeed now)

[seba--]

@andiderp Can you have a look?

[andrepacak]

Isn't this the normal behaviour? Failing builders are not rebuild therefore you have to clean first.

[seba--]

For non-remote builders: if no required file changed, a rebuild has no chance of success.

For remote builders: if no required file changed and no required remote changed, a rebuild has no chance of success.

In a sound incremental build system, you never have to do a clean build.

[andrepacak]

Will look into that.

[andrepacak]

One problem in the GitRemoteSynchronizer is that the RemoteRequirement is registered after the clone happens. If the clone fails the requirement is never registered. We want the timestamp file of the RemoteRequirement to be in the .git directory but we cannot clone a repository into an non-empty directory. Thats why the requirement is registered after the clone. We need a better path for the timestamp file.

[andrepacak]

@seba-- Where exactly does the algorithm determine if a builder has failed previously and checks if the requirements have changes their consistency statues?

[seba--]

Check requirements: https://github.com/pluto-build/pluto/blob/master/src/build/pluto/builder/BuildManager.java#L327

If the builder failed before and the requirements did not change, yield throws an exception https://github.com/pluto-build/pluto/blob/master/src/build/pluto/builder/BuildManager.java#L384