Commit Graph

12 Commits

Author SHA1 Message Date
Iuri Matias d5cd0b0ff7
address code review 2018-10-23 11:12:00 +02:00
Iuri Matias b06d224883
fix services & processes; improve UI 2018-10-23 11:11:58 +02:00
Pascal Precht 64d8fa3368
feat(core/processManager): introduce `processes:stop` handlers
So far, `ProcessManager` was able to only register a `process:launch` handler.
There was no way to tell `ProcessManager` how to stop processes. This hasn't
been a problem so far as most of the service processes can be started without the usage
of the `ProcessManager`, but turns out to be necessary if we want Embark UI to be able
to pick up running services.

A good example is the webserver process, which until now bypasses the `ProcessManager`
all together. The webserver sets up two event handlers to start and stop it respectively:

```
this.events.setCommandHandler('start-webserver', () => this.server.start());
this.events.setCommandHandler('stop-webserver', () => this.server.stop());
```

In the future, this should happen through the `ProcessManager` instead, so the webserver
process can be picked up by Embark UI, like this:

```
this.request('process:register', 'webserver', () => {
  this.server.start();
});

// and then

this.request('process:launch', 'webserver', () => {
  // server started
});
```

Notice that the given callback to registering a process is actually the function that
gets called to launch the process.

Having that in mind, and considering that we also need a way to stop the process through
`ProcessManager, so we don't introduce a regression, we need a way to register a stop
call back as well.

The new API introduced in this commit looks like this:

```
this.request('process:register', 'webserver', {
  launchFn: (callback) => { this.server.start(callback) },
  stopFn: (callback) => this.server.stop(callback) }
});

// and then

this.request('process:launch', 'webserver', (err, message, port) => {
  // server started
});

this.request('process:stop', 'webserver', err => {
  // server stopped
});
```

Notice that `process:register` works exactly the same way as before as well.

Another thing to notice is that all parameters emitted by the underlying process
are propagated to the outside caller, which is why `err`, `message` and `port` are
available inside the launch callback.
2018-10-23 10:57:05 +02:00
emizzle 7de72cb474
Addressed PR feedback
- Created an “embark” module so that an “embark” process could be registered in the correct way. This service is only used on `embark run` (can be extended to other commands if needed).

- extracted “embark” to a const `DEFAULT_PROCESS` param in the `Console` component.

- extracted commands result rendering to it’s own function to keep the `renderTabs` function from getting cluttered

- Added sorting of logs by timestamp

- Added milliseconds to the log file data (which helps in sorting log messages).
2018-10-23 10:53:25 +02:00
emizzle 42cc9b559f
Fills embark logs tabs with existing embark logs
A logfile is now generated by default, in the format `.embark/embark-log__YYYY-MM-DD_HH-mm-ss.log`.

When the home tab is loaded, the process logs are fetched for all the processes. The list of processes returned now includes `embark`, and when `/embark-api/process-logs/embark` is fetched, the logFile is parsed and an array of log messages are returned.
2018-10-23 10:52:26 +02:00
Anthony Laibe 1bd5174f61
Adding new reducer and selector 2018-10-23 10:27:42 +02:00
Jonathan Rainville d6977507b6
add tabs for the processes 2018-10-23 10:23:44 +02:00
Jonathan Rainville 640ec0b761
change route name 2018-10-23 10:23:44 +02:00
Jonathan Rainville 459d0cc2d6
small conflicts 2018-10-23 10:23:43 +02:00
Iuri Matias 3a532a05e8
move processes into core 2018-10-23 10:15:29 +02:00
Jonathan Rainville 363608287f fixes and linting 2018-08-21 16:05:59 -04:00
Iuri Matias 29b0d01f22 move processes into core 2018-08-21 16:04:22 -04:00