[Suggestion] Github CI
Closed this issue · 23 comments
Good idea.
So, every time a commit is pushed to a github-project master-branch, the CI Server builds it using Howl and uploads it as a release to github? Or does it put the build on a website, like jenkins for example?
wasn't thinking of uploading the build, that's a good idea
Ahhh, saw this after the post on idea exchange:
The hardest part would be an extensible emulator (preferably one that can easily be configured/run from the command line). I started one a way back, but gave up. Might have another look at writing one. Then you could just setup some sort of configuration for Travis using it.
I posted some stuff on the forums again (we are going to be bouncing back and forth, perhaps stay on forums until the topic there changes?)
Have the CI server host a minecraft server (the software is free and doesn't require an account). One computer in spawn with our/your CI script and perhaps a TE autonomous activator to bypass the no-auto-turn-on bug. You'd have problems getting it to work on request, but it would work.
Could have the software run on a CC computer in minecraft. I'm sure their is a server somewhere which everyone frequnts or a spare computer which can have their own server
Ugghghrhrh, the hacks!
I'd prefer to stay on GitHub, mostly because I get notifications (and Ajax).
I think it'd be easier to build an emulator that fits our needs instead of letting the application start a minecraft server ^^
There are some löve-based emulators out there, they can easily be modified, maybe we can ask the owners if we're allowed to use them as a code base.
Or even better: we make Howl löve-compatible and use löve to run Howl directly, instead of using an emulator
Howl does run in standard Lua, so using normal Löve is a possibility.
One of my many projects at the moment is extracting CCTweaks' code into a standalone project. I'm planning to build an emulator off that which could be useful for this.
One of the difficulties with this would be recording terminal - I think recording to GIF would be pretty cool, but then you need some sort of storing it. I'm personally not prepared to host this sort of service, so building it through Travis would be preferable.
Good luck with the emulator @SquidDev, looking forward to it! @ardera CCLite is open source AFAIK (https://github.com/Sorroko/cclite#license), but as SquidDev said you don't have to use it cause Howl is compatible with normal Lua.
That would be really useful. Will it output ANSI escape codes? Something which would be really useful would be to output the terminal calls and a timestamp: this way you can reproduce terminal output and render it as a gift, HTML canvas, etc...
Hmm, that could work. My idea had been to just listen on a particular UDP socket and output all relevant calls there.
I'll open an issue in CCEmuX to discuss it more.
I've been working on this behind the scenes a little so I'll document my plan and what I've currently got working:
Instead of hosting my own CI server I'm just going to use Travis and execute scripts through an emulator. There will then be a web interface to view Travis logs in the TRoR format and render them as a terminal. Each packet will include the computer id and a timestamp to allow rendering them in the correct order.
Emulator
We could either use CCEmuX or roll our own.
I'm probably going to need to inject custom APIs into the environment (to allow passing environment variables, marking the build as failed, etc...) so it might be more beneficial to roll my own. If we do go that route then I'd want it to be compatible with CCEmuX: the ci API should provide the same methods and allow setting the same config values.
The advantage of using CCEmuX is that we don't need to bother remaining compatible with other emulators, and we get all the nifty features that are already there.
Web interface
The advantage of using Travis to build things is that I don't need to host anything. We can instead use the Travis API to fetch build information and extract terminal data from the log to render a terminal. We may wish to add support for other CI systems too.
Initially we won't stream the logs so you will only be able to view the terminal once the build has finished. A future enhancement would be to render the terminal as the build progresses.
We will also need to be able to handle multiple jobs per file as people may wish to configure the build matrix to run multiple CC versions or with and without CCTweaks.
Extensions to TRoR
We will use the TRoR protocol to store the terminal state. Each packet will be annotated a unique identifier and the result of System.nanoTime(). Alternatively we could use System.milliTime() and an incremental packet id.
We will also extend the protocol with several X* packets:
XD: A log entry of level "debug".XW: A log entry of level "warn".XE: A log entry of level "error".XS: Marks the current build with a status: either "success", "error" or "failure".
It might be worth considering a single XL packet which takes a log level and a string.
The one issue I've had so far is that the window API will render the entire terminal each time it is changes, resulting in significantly larger log files than expected. We could use an extension as discussed here though that would result in no other implementation being able to read the logs.
At the most basic level you could just grep the stdout for calls to ccemux.echo(...) to get output from a startup script.
Anyways, once the new TRoR spec is finalized I'll be implementing it as a configurable option for CCEmuX. Would you prefer output to a network socket or to stdout?
Would it be possible to redirect ccemu.echo to the renderer instead?
Would you prefer output to a network socket or to stdout?
It should be possible though you'd either need to wrap stdout as a channel or the socket as an output stream.
I was thinking about making it use IO streams anyways, I like writing modular code 😛
What do you mean by redirecting ccemux.echo to the renderer? As in letting the Renderer implement a handler for it?
What do you mean by redirecting
ccemux.echoto the renderer? As in letting the Renderer implement a handler for it?
Yep. This means it is easy to tell which computer echoed (as the TRoR renderer would include the ID). Swing would probably ignore it, though could display it in an info bar or something. Dunnoh.
It already includes the ID, ccemux.echo calls show up like this:
[Coroutine-3] INFO CCEmuX - [Computer 0] Hello World!
It's also independent of the renderer in use.
Guys
Any feedback welcome: you're probably better off creating an issue on the actual repo. There is a lot of work to be done: I need to support multiple computers, multiple jobs, and improve the terminal rendering controls. Progress though!
Here is an example of it in action: wait til it gets half way across then keep your eyes open.
Well that was quick, nice work!
Yeah, it was put together quite quickly and so isn't anywhere near polished: this is very much a proof of concept.
Are you still planning to use CCEmuX, or are you going to keep on writing your own emulator?
@apemanzilla I don't know: see the emulator section of this comment.
In the short term it was easier to dash up something together in a couple of hours then add what I wanted to CCEmuX. However, I don't really want to be developing an emulator here: there are a ton of features missing that I've no inclination to add, hopefully CCEmuX will fill that gap.
I've created an issue about this particular problem (SquidDev-CC/howl.ci#1)
I'm about to release the initial version of howl.ci so I guess we can close this issue. 🎉 ✨ 🍕