Ethan Atkins df5f9ae3cb Support commands in continuous ... I had previously not though there was much reason to support commands in continuous builds. This was primarily because there were a number of questions regarding semantics. Commands cannot have fileInputs specifically assigned to them because they don't have an associated scope. They also can arbitrarily modify state so what is the expectation when running ~foo where foo is a command that, for example, replaces itself. I settled on the following semantics: 1) Commands run in a continuous build cannot modify the sbt execution state which is to say that the state that is returned by continuous is the same that was passed in (unless a reload occurred or we exited the build with an exception) 2) Any global watchTriggers or fileInputs apply to a watched command. They automatically inherit any fileInputs that are queried when running tasks in a command. So, for example, ~+compile does what you'd expect. The implementation is fairly straightforward. If we can successfully parse a command, but we cannot parse a scopedKey from it, we assign it a private ScopedKey. When computing the watch settings for that key, we will select the global settings through delegation. This is how it picks up the global watchTriggers. To run the command, I had to rework the task evaluation portion because a command may return a state with additional commands to run. The cross build command works this way. We recursively run all of the commands starting with the original until we run out of commands to run. As part of this work, I was able to remove the three argument version of Command.processCommand that I'd previously added to support my old approach to evaluating commands. This was a nice bonus. I added scripted tests that check that global watchTriggers are picked up and that commands that delegate to a command that uses fileInputs automatically pick up those inputs during the watch. I also added a test that approximates the ~+compile use case and ensures that the failure semantics are what we expect and that the task runs for all defined scala versions.		2019-06-01 20:10:26 -07:00
..
src/main/scala/sbt/scriptedtest	Support commands in continuous	2019-06-01 20:10:26 -07:00
NOTICE	create scripted-sbt-redux	2018-07-10 03:13:47 -04:00