Make git calls testable #299
Assignees
Comments
teggotic
added a commit
that referenced
this issue
Feb 15, 2023
There is an issue in how we test actions. Fundamentally, we rely on the fact that the `Real` runner is generating `git` calls correctly. This could be neglected in theory, but there is another issue, which forces us to generate "textual" representation of what our command is doing, in multiple places, which leads to code repetition. As a solution to this, I've created 1 data type for every type of the command we can execute, and implemeted the way to render it to the "textual" representation. This could be used by `Real` runner directly, but this still suffers from a different issue. We give `Real` runner to much access, by adding `MonadIO` to the context. There is a solution however. We can create a custom `Monad` which can provide all needed functions for `Real` to proceed. Going this way, we can hide how we "render" and "execute" git calls from the `Real` runner, which implies that it has no way to run arbitrary commands at all. #299
4 tasks
teggotic
added a commit
that referenced
this issue
Feb 15, 2023
There is an issue in how we test actions. Fundamentally, we rely on the fact that the `Real` runner is generating `git` calls correctly. This could be neglected in theory, but there is another issue, which forces us to generate "textual" representation of what our command is doing, in multiple places, which leads to code repetition. As a solution to this, I've created 1 data type for every type of the command we can execute, and implemeted the way to render it to the "textual" representation. This could be used by `Real` runner directly, but this still suffers from a different issue. We give `Real` runner to much access, by adding `MonadIO` to the context. There is a solution however. We can create a custom `Monad` which can provide all needed functions for `Real` to proceed. Going this way, we can hide how we "render" and "execute" git calls from the `Real` runner, which implies that it has no way to run arbitrary commands at all. #299
teggotic
added a commit
that referenced
this issue
Feb 15, 2023
There is an issue in how we test actions. Fundamentally, we rely on the fact that the `Real` runner is generating `git` calls correctly. This could be neglected in theory, but there is another issue, which forces us to generate "textual" representation of what our command is doing, in multiple places, which leads to code repetition. As a solution to this, I've created 1 data type for every type of the command we can execute, and implemeted the way to render it to the "textual" representation. This could be used by `Real` runner directly, but this still suffers from a different issue. We give `Real` runner to much access, by adding `MonadIO` to the context. There is a solution however. We can create a custom `Monad` which can provide all needed functions for `Real` to proceed. Going this way, we can hide how we "render" and "execute" git calls from the `Real` runner, which implies that it has no way to run arbitrary commands at all. #299
teggotic
added a commit
that referenced
this issue
Feb 19, 2023
There is an issue in how we test actions. Fundamentally, we rely on the fact that the `Real` runner is generating `git` calls correctly. This could be neglected in theory, but there is another issue, which forces us to generate "textual" representation of what our command is doing, in multiple places, which leads to code repetition. As a solution to this, I've created 1 data type for every type of the command we can execute, and implemeted the way to render it to the "textual" representation. This could be used by `Real` runner directly, but this still suffers from a different issue. We give `Real` runner to much access, by adding `MonadIO` to the context. There is a solution however. We can create a custom `Monad` which can provide all needed functions for `Real` to proceed. Going this way, we can hide how we "render" and "execute" git calls from the `Real` runner, which implies that it has no way to run arbitrary commands at all. #299
teggotic
added a commit
that referenced
this issue
Mar 5, 2023
Values to `git config` should be quoted to work properly, otherwise they (specifically aliases) would be set as multi-value configs. However, if we just blindly change this to be quoted values, we would split them into separate arguments for a proc, which would lead to the same issue. To improve this, we just need to use `[]` instead of `Text` for command args. Note: I've switched to "raw strings" (`[s|raw string|]`) in `AcquireRepositorySpec.hs` to remove escaping of double quotes. #299
teggotic
added a commit
that referenced
this issue
Mar 5, 2023
Values to `git config` should be quoted to work properly, otherwise they (specifically aliases) would be set as multi-value configs. However, if we just blindly change this to be quoted values, we would split them into separate arguments for a proc, which would lead to the same issue. To improve this, we just need to use `[]` instead of `Text` for command args. Note: I've switched to "raw strings" (`[s|raw string|]`) in `AcquireRepositorySpec.hs` to remove escaping of double quotes. #299
extsoft
pushed a commit
that referenced
this issue
Mar 15, 2023
There is an issue in how we test actions. Fundamentally, we rely on the fact that the `Real` runner is generating `git` calls correctly. This could be neglected in theory, but there is another issue, which forces us to generate "textual" representation of what our command is doing, in multiple places, which leads to code repetition. As a solution to this, I've created 1 data type for every type of the command we can execute, and implemeted the way to render it to the "textual" representation. This could be used by `Real` runner directly, but this still suffers from a different issue. We give `Real` runner to much access, by adding `MonadIO` to the context. There is a solution however. We can create a custom `Monad` which can provide all needed functions for `Real` to proceed. Going this way, we can hide how we "render" and "execute" git calls from the `Real` runner, which implies that it has no way to run arbitrary commands at all. #299
extsoft
pushed a commit
that referenced
this issue
Mar 15, 2023
Values to `git config` should be quoted to work properly, otherwise they (specifically aliases) would be set as multi-value configs. However, if we just blindly change this to be quoted values, we would split them into separate arguments for a proc, which would lead to the same issue. To improve this, we just need to use `[]` instead of `Text` for command args. Note: I've switched to "raw strings" (`[s|raw string|]`) in `AcquireRepositorySpec.hs` to remove escaping of double quotes. #299
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: