You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 21, 2021. It is now read-only.
I am thinking about using this repository to create an integration build, that can be run either in a pipeline (which would mean moving to a different CI provider, since travis doesn't really support build pipelines) or scheduling to run daily.
The idea is that we create an integration testing project, which executes a much broader range of cloud haskell libraries against a much broader set of use cases. A set of stack-X.yaml configurations can pull in the very latest of a matrix of our dependencies, and test accordingly. This would allow us to verify multiple configurations of things that are not limited to distributed-process, but could also pull in and utilise stuff like simplelocalnet, multiple alternative network-transport implementations (e.g., 0MQ, named pipes, CCI, etc), exercise some of the platform libraries like d-p-task, d-p-execution, d-p-supervisor, and so on.
We could also use this capability to exercise tests that run multiple executables.
I will do some further investigation on various CI provider options, and post back my findings.
The text was updated successfully, but these errors were encountered:
@facundominguez @qnikst - any objections to this idea (below)?
I am thinking about using this repository to create an integration build, that can be run either in a pipeline (which would mean moving to a different CI provider, since travis doesn't really support build pipelines) or scheduling to run daily.
The idea is that we create an integration testing project, which executes a much broader range of cloud haskell libraries against a much broader set of use cases. A set of
stack-X.yaml
configurations can pull in the very latest of a matrix of our dependencies, and test accordingly. This would allow us to verify multiple configurations of things that are not limited todistributed-process
, but could also pull in and utilise stuff likesimplelocalnet
, multiple alternativenetwork-transport
implementations (e.g., 0MQ, named pipes, CCI, etc), exercise some of the platform libraries liked-p-task
,d-p-execution
,d-p-supervisor
, and so on.We could also use this capability to exercise tests that run multiple executables.
I will do some further investigation on various CI provider options, and post back my findings.
The text was updated successfully, but these errors were encountered: