similar to a hybrid of the random facts (but defined more simply) and
the dice rolling (but not picking from dice), this allows for definition
of "choice sets" (only in the admin for the moment) and then getting a
random pull from that set (only in the web interface for the moment)
when assigning a new user for review/acceptance, use their real name in
the message, not their username (the reassign will include their
username a split second later anyway)
the theory here is that counting the number of sentences generated is
kind of silly, if we're already specifying min/max word counts, we
probably just want to fall into that range, and not really care how many
sentences we get
meanwhile, we were overloading max_sentences to also calculate how long
any one sentence must be, which is kind of a weird thing to derive, so
we're going to drop the max_sentences language and call this more what
it is, a bias towards the number of sentences that might be seen
This reverts commit 464727cc74.
it turns out that without the min_words_per_sentence adjustment, the
default min_words (15) is way too demanding on a lot of chains, so we're
going to go back to this for the moment
this puts additional pressure on the sentence generator, retrying many
times to get something that's long but not too long. only testing on a
small context so far, so this is certainly not yet ready to go live, but
the results are pretty good so far
this tunes things a bit in the sentence generator, trying to favor
complete sentences over the min/max word counts, which are still kinda
heeded but not as militantly. this *should* create more interesting
chains, especially with topics, without really breaking things, but this
certainly needs some testing before we can see if it's actually right
bot was overzealous in logging the approval reset message when seeing
pushes. this commit should keep it from logging the message if a push
happened but there weren't actually any approvals yet (so there's
nothing to reset)
still waiting on testing, but this seems like a decent fix to me
bss/dr.botzo#4
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
Brian S. Stephan