ProcessManager can be used to "register" processes and along with it, a launch function
that will be executed when a process is requested to launch.
Prior to this commit the IPFS process has not be registered and launching the process
was done manually, bypassing ProcessManager APIs.
With this commit we take advantage of ProcessManager APIs to register the IPFS process
and launch it using the `process:launch` event.
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.
After the code was rebased, there were some additional changes for getting websockets logs that needed to be catered for.
When there is a call to get all logs for a process, the state entity is updated with a new array item containing all the logs (this is then reduced and selected for rendering). In the case of a websocket log that simply returns only one log item, the latest full log for the process is found in the state entities, and it’s logs are appending to with the data from the websocket.
Additionally, log limits were updated to be passed in as a parameter to the API calls from the frontend. Parameter validation (for `limit`) was also added in this commit.
*Console.js*
- Moved `DEFAULT_PROCESS` const to outside of the `Console` class (but inside the module).
- Removed `(` and `)` from `.filter` in `getProcessLogs()`.
- Updated comments
*logger.js*
- Moved `dateFormat` and `logRegex` to constants outside of `Logger` class
- Moved the `parseLogFile` method inside of the `Logger` class (ES6 style)
- Added a log limit to the `parseLogFile` method
- Added the log path to the constants file and used inside of `Logger`
*cmd_controller.js*
- Defaulted `this.context` to `[constants.context.any]` in the constructor.
- Changed `’embark’` to split modules`coreProcess` and `loggerApi`.
*engine.js*
- Changed `’embark’` to split modules`coreProcess` and `loggerApi`.
The embark log file is being overwritten each time embark is run. There is a separate log file for each context, so that running, for example, `embark run` then `embark console` doesn’t get the `run` log overwritten with the `console` log.
- 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).
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.
Some strings were being logged as
```
[w,r,i,t,i,n,g, ,f,i,l,e, ,,[,2,m,,[,1,m,.,e,m,b,a,r,k,/,s,t,a,t,s,.,r,e,p,o,r,t,,[,2,2,m,,[,2,2,m]
```
The fix was applied to the `normalizeInput` method which simply returns if the input was a `typeof` string.
- Add no cache via helmet
- Fix linting (no-return-else)
- Rebase Fix: Use option.name for process log to avoid endpoint being called
blockchainProcess.js
- Rebase Fix: use option when compiling solidity
Fixed issue with contract deploying for first time and having no gasLimit specified.
Optimised/refactored looping of compiled contracts.
Added body parameter type checking for `/embark-api/contract/deploy` endpoint
Handle use cases:
1) handle case when temp.sol doesn’t exist - due to the new saga updates, the response from retreiving a temp fiddle from the filesystem (even if it doesn’t exist) is forward to the compilation endpoint, which returns an ENOENT, and this is handled in the selector.
2) delete all code - shouldn’t return last fiddle and should compile an empty string.
3) Switch to different tab (ie contracts) then back to fiddle - previous fiddle should remain.
Also fixed an issue (most likely due to latest rebase) when deploying fiddle contracts. The gasLimit was not being specified.
Handled issue where entities stored in the state were not being put in the correct order, so a timestamp was sent with the requests and then sorted when the response was returned.
1) hanlde case when temp.sol doesn’t exist
2) delete all code - shouldn’t return last fiddle
3) Switch to different tab (ie contracts) then back to fiddle - fiddle should now remain.
Fiddles are now stored in the filesystem so they can be preserved across page reloads, but also so that contracts deployed via fiddles can have their source code shown.
Fiddles deployed as contracts now fully work with existing contract list UI and functionality. Fiddle deployed contracts are listed in a separate section in the UI.
Current limitation is that only single contracts per file are supported. If the fiddle contains multiple contracts, it’s currently not supported.
Fiddle is properly deploying now, except the source code needs to be saved to the filesystem in order to be recalled later.
Fixes for handling errors on deploy and compilation.
Update contract state UI for determining state / interface / deployed.
Fixed browser errors caused by tabler (bodyItems and headerItems complaints) as well as staticContext issues caused by using withRoute(NavLink)
Also added a response to fiddler deployment.
Added loading states to fiddler results, that shows the errors/warnings as having a loading state when compiling/deploying
Richard Ramos
Iuri Matias
Jonathan Rainville
Anthony Laibe
Pascal Precht
emizzle
Andre Medeiros