Establish sufficient testing #3
Comments
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
mih
added a commit
that referenced
this issue
Sep 11, 2023
More/most procedural knowledge is in scripts now. Most settings are in dedicated environment variables now. Especially the latter aims to promote a test battery implementation that does NOT depend on a particular CI setup, but could (also) be executed against a real server target. There is now a clearer separation of platform CI runs in the form of appveyor matrix runs. CI stages that require a different implementation are now also presented in different segments (in contrast to the line-by-line mixing before (and elsewhere). The target setup uses a Docker-based deployment of an SSH server on all platforms that support it (Linux, Windows). This enables comprehensive client code test implementation for Windows, without being limited by a non-POSIX server-side. This is a major step towards addressing #3. The docker container images are now built in a separate project and are downloaded from the respective appveyor build artifact URLs. This new scoping should discourage overfitting the basic Docker setup with RIA test specifics. The purpose of the SSHD container is to expose a local path via SSH to enable testing generic SSH operations. This should be all that is needed for RIA SSH functionality testing. There is no Docker deployment available for appveyor Mac workers. An attempt to deploy it manually has not yielded a _reliably_ working system with a sensible deployment cost. As a consequence, the Mac CI runs will use SSH-access to "self" (the exact same worker environment via a localhost SSH connection). This is not ideal, but an acceptable compromise. Closes #51
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
[Taken from RFD]
We need to implement testing that at least includes the following:
The text was updated successfully, but these errors were encountered: