this moves a bunch of code around and renames a bunch of things, so the
diff for it is fairly huge, but it's the same general idea, just
organized better. woo.
the code review logic to this point is kind of convoluted, and still is
for the moment, but this moves some of the stuff into a more coherent
spot in the expectation of reuse. most of the refactoring is still to
come
the intent of this thing is to scan configured projects' merge requests,
and automatically assign them to designated code reviewers. if someone
says "LGTM" in the merge request thread, that counts as a review and the
bot either selects another reviewer or assigns the thing to a designated
merge approver for the final approval and merge
this is most of the way there, but not done yet. things still to do:
1) more strings than "LGTM", but we should be careful to avoid things
that someone might actually say
2) i'm trying to avoid it but i probably need to track the 2 of 2
reviewer message separate from the message assigning the merge
request to an approver. it's plausible that a reviewer is also an
approver, and if the last reviewer is a candidate approver, the
script does nothing, but we probably want it to still log the 2 of 2
part. i could track the "nagging" for 2 of 2 messages, to avoid
the bot repeating itself, but that seems unfortunately annoying
i tried to use this for datatables, but it was taking too long to get a
response, so i'm abandoning this for the moment, but the support's there
for the future
if there's a ton of data points, the graph starts looking real gross,
so do a couple things to make the display of that a bit simpler so
there's less noise and distracting lines and whatnot
for the moment this is for the password change url used in the auth
dropdown, and a better login page, but this might become other stuff
eventually too. the signup page exists and is linked to, even if i don't
have a great reason for this to exist
bunch of templates added now to support the intentional and
unintentional stuff
_return_tweet_or_retweet_text used to both determine the proper tweet
text and bot.reply() with it to the provided event. if we're not
reacting to an irc event, this obviously won't work, so this pulls the
method into two things so that we can use the string formatting code
without necessary needing an event
this removes an old, general field, which was once used for multiple
things, but we should break apart its functional usage and also just
refer to our IrcChannel object anyway
this is the easy half of issue #3
in addition to being a convenient unload plugin, load plugin, this also
uses importlib.reload() to kick the interpreter to reload changed code
inside the plugin's package, if the user requests to reload the entire
package. this seems safe so far
(famous last words)
this shouldn't have happened, but i'm guessing some previous crash put
some buggy data into my database, so let's just be careful and do this.
a k1,k2 could have had any value for v, but not knowing what else to do
in this corner case, we'll just use a stop and let the caller decide
if they want to keep going
get rid of is_admin(), instead check for django permissions. a couple
things were using is_admin(), so now there's an example of the
permission adding and usage, as those were ported
sets up the foreign key and changes how is_admin() works, though it will
be going away pretty soon, i just need to do this migration in parts so
as to not confuse django too much
this silly storytelling game has been lightly tested, but it appears to
not blow up miserably, so i'm going to commit it until i can spend more
time testing it/caring about it
decouple the dispatcher (a key, basically) with the actions to take upon
receiving such a message. allows us to have multiple actions for one key
without weird hacks
use GenericAPIView rather than APIView in order to get some common idiom
stuff done for us. we continue to support GET and POST in
DispatchMessage, now it's just a bit cleaner. i think.
anyway if we were doing this stuff more we could/should probably create
mixins for them, but at the moment this is pretty sane i think
this moves the dispatcher functionality that used to be in the old
ircbot directly to django REST framework, which is more robust and
allows for cooler stuff down the road. this still retains the ability to
have the bot privmsg, that still happens over the XML-RPC interface,
this is just a more convenient frontend to that
Brian S. Stephan