Closed KubaO closed 3 years ago
I've looked at this as well (although focus has been on Jenkins integration lately), and it's really an exciting idea. Don't see any reason why it wouldn't work, while giving a lot of value.
I think going the autohotkey-route would probably violate some licensing rules (although the purpose of having the license is just to run tests, and not actual production code, but I don't think Beckhoff would want to differ between these two). I've got some spare PLCs as well, so setting this up for a project (for example TcUnit-Verifier or some other test project using TcUnit) would be interesting.
Just wanted to say that Jenkins integration is complete. See:
@KubaO I'm moving this to the discussions of TcUnit, as there has been over one year since this issue was created and I think this is more suitable in the discussions.
CI should be enabled as a part of the normal TcUnit dev process. AppVeyor integrates with GitHub and would automatically greenlight pull requests. This would also be a good example for any other TwinCat project. Notes:
AppVeyor free tier should be sufficient: the VMs have two cores, so we can have a preconfigured image with TwinCat3 with one core dedicated to TwinCAT, another one to Windows. This will allow running the PLC in a virtualized environment.
AutoHotkey could be used to answer the license prompt. Alternatively, I can provide a "bring your own cloud" TC3 machine (say CX5120) exposed to AppVeyor, so that the CI would still be managed by AppVeyor, but the actual test run would use hardware licensed for TC3.
A different option that would vastly decrease the burden of testing is to convert the binary TwinCat compiler output
.app
to a.obj
file, add some C-to-Pascal calling convention shims, and run the test suite as a regular .EXE. This would require implementing a few of the functions that are provided by Beckhoff (i.e. faking an ADS log target). I have prototyped this approach so it's viable; the.app
file has a simple structure. It's not published yet, but I will release it if there's interest. It's not hard to make it robust i.e. produce results that won't differ from results on a "real" TwinCAT runtime. The test suite has no realtime requirements, so that's not a concern, and it has very low use of library functions.60 has to be resolved in some way.
This is not a duplicate of #7, since Jenkins integration is a separate concern (and just as useful).