Discussion issue for "Lint code in the Web IDE and provide actionable data for resolution"
This issue is related to #5428
We identified four ways to implement this:
One global pipeline running always, and using a custom image with rubocop and eslint installed, that would accept requests for every project. I have two concerns about this approach. The first one is about scalability. I don’t think one pipeline can hold all requests coming from every instance of the web IDE. We would need some sort of Kubernetes pod that can spin up other containers based on some hw and network parameters. The other concern is security. We will be sending information of all projects to the same container. There could be some sort of breach that could leak private information. Nevertheless, from the overall perspective, this is the more reasonable approach because there is no waiting time for the pipeline to start and because we save runner minutes. This option wouldn't involve modifying the
The second option is to run, automatically, a pipeline every time an instance of the web IDE loads. Since we can have many different kinds of projects me might be wasting runner minutes if the project language is, for example, python. Therefore, I suppose we should let the user opt-in for this feature inside the
- There can be some optimizations here like, instead of spinning up a pipeline every time an instance of the web IDE loads, we can reuse the same linting pipeline for all instances that belongs to the same project.
- The problem with this approach would be to keep the pipeline running while there is at least one instance of the web IDE running and, at the same time, stop the pipeline once there is no more web IDE instances of that project opened.
The third option would be to run the linting inside the web IDE terminal. This will require two things:
- The image defined in the
eslintinstalled. This is more painful for users.
- The user has to click on the web ide terminal to start the linting.
- The problem for this approach as well would be that we depend on the web IDE terminal life cycle to have linting. If, at some point, the web IDE terminal life cycle differs from the linting one, we will have to reimplement all the logic.
The fourth option would be a similar approach that we took for CI linting. This will involve creating an API endpoint for linting. Once we receive the request we can call the local binaries
eslint to parse the content in the request. This can affect global server performance since they can be accepting a lot of requests.
Each option has its pros and cons.