I mean I don't even know how easy it is to switch adapters tbh. I'm sure it's something not a big deal. But the whole point is to test interfacing with a discourse env. I don't think we change it you just need to update the envs of your local to point to valid endpoints.
I'm open to anything
o i think i misunderstood you. the thing i linked are mock adapters, for use with stuff like feature tests. sounds like what youre talking about is something like integration tests, which would be like additional tests within the hubot-
nevermind. i went to open the hubot-discourse-adapter page and there are no fucking tests lmfao. https://github.com/featheredtoast/hubot-discourse-adapter kinda worrisome. i could maybe look into how people usually setup those suites and then make a public commit here but it would be way better if we used an adapter with an existing test suite so i could just verify that there are integration tests and we wont have to write any
well i think im just gonna init a sails.js project since the architecture should mimic discourse's code and write some get post requests with Postman. you'd probably have to worry about trying to figure out how to rewrite mafiabot to communicate with my API instead.
how do you think you would go about that? and interface w my api
I don't know what sails is, what what the api do?
sails is just an mvc framework for node like express, i just dont want to use express. i would be manually making the endpoints for the bot. it would handle mafia gamestate and then mafiabot can just pass queries to it and spit back whatever it says. the end result should be something that you can easily run in a pm2 instance on docker or whatever
it just seems really annoying hwo we have it architected right now, atleast from my memory. this is closer to what i was suggesting in the past when i was trying to show you rubygems that handle gamestate ands tuff
yes mafiabot will be tightly coupled to it but i think itll make it easier to develop+test in the long run and meant that we could consider hosting nondiscourse alternatives, as long as they fit the api
so instead of mafia handling the db interactions you want to send the data to your node app to do the processing and db interactions.
sounds interesting. im pretty sure i gave you all the access you need for the db a long time ago.
yea but i forgot most of that shit
guess i should just check our pm logs
another day, another js framework
If there was a way for someone like ironstove to easily write new bot commands, deploy them and test them on the website, then share them with you guys to be merged into mafia bot that would be great
The easiest way I can see to do that is a "test bot" which people can push new code to and deploy
Also there would be no coffeescript in this magical hypothetical
1 Like
What was the reasoning behind CoffeeScript over plain JS? Dan's familiarity with Ruby? Tbh, if there's a rewrite, it'd be much more stable with Python via Flask
iirc roragok wanted to use it and i said sure why not cuz it didnt seem like a problem then
you might be right but i havent used python in a minute, if you or istove wanna help out there that'd be good
whichever one of you is too lazy to code (likely ewiz) should figure out the structure of the api
I'm lazy at, but would be fine writing the API design documentation for stove to use. But if he doesn't know flask, I should probably do it.
I also haven't worked with discourse's API, so I'd have to learn that if I code it. I'd be fine with that if someone else adds the verification and security afterwards: I hate doing that shit
stove prolly doesnt know flask but he seems like he'd be familiar with crud type stuff
and we were talking about rewriting the code but we/i dont have any plans to add the discourse interfacing to the mafia-server, cuz it doesnt sound worth it to roll our own hubot to interface with discourse. in my mind ideally we'd have this mafia-server handling game, gamestate, etc, and then we can transition mafiabot to focus entirely on presenting, and we never have to worry about writing discourse-facing code inside of the mafia-server
im not experienced enough to understand how exploitable the API could be but i would gladly take it on if it meant you would be more apt to work on the mafia-server thing with me. the mafia-server would only really interface with mafiabot though -- i guess we could add some alternative endpoint in the future like a staff portal to manage and correct games, but that's the only other nonbot endpoint i can think of.
Oh, I just mean discourse's API for consuming posts/threads and posting to them, which is already handled by mafiabot.
I'm not familiar at all with how mafia-server works: what's going on there?