New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Add 'rerun test' button #1779

Closed
wants to merge 1 commit into
base: develop
from

Conversation

Projects
None yet
6 participants
@AdamWill
Contributor

AdamWill commented Aug 30, 2017

This adds a 'rerun test' button to the 'Automated Tests' tab,
which causes Bodhi to send out a fedmsg requesting that the
test system re-run the test.

Well.

That's what I WANT it to do. What it actually does is add an
API endpoint for doing that, and add an icon that does nothing
at all to the 'Automated Tests' tab. Cleanly having that icon
act as a button that sends the post request is apparently beyond
my (more or less non-existent) Javascript skills right now, so
if someone wants to show me how to do that, I'd be grateful...

Also, no tests yet, will do that soon.

WIP: Add 'rerun test' button
This adds a 'rerun test' button to the 'Automated Tests' tab,
which causes Bodhi to send out a fedmsg requesting that the
test system re-run the test.

Well.

That's what I WANT it to do. What it actually does is add an
API endpoint for doing that, and add an icon that does nothing
at all to the 'Automated Tests' tab. Cleanly having that icon
act as a button that sends the post request is apparently beyond
my (more or less non-existent) Javascript skills right now, so
if someone wants to show me how to do that, I'd be grateful...

Also, no tests yet, will do that soon.
@AdamWill

This comment has been minimized.

Show comment
Hide comment
@AdamWill

AdamWill Sep 1, 2017

Contributor

@ryanlerch has been volunteered to help with this ;)

So the obvious UI problem for the button is that, right now, all bodhi can know for openQA tests is that it sent the fedmsg requesting the test be rerun. It doesn't know if the test actually got rescheduled, or when it's running, or anything like that. This is also true right now for Taskotron tests - we could fix that using ExecDB, but not in the Javascript.

So for right now I'd suggest we just do a bit of a hack like popping up a 'test rerun requested' notification and hiding the result row. If the user reloads the page they'll see the old result and the 'rerun test' button again, which is unfortunate, but shouldn't have any too grievous consequences (sending multiple 'rerun test' requests won't do anything too terrible at least for openQA, it'll effectively just ignore duplicated requests, I can't speak for Taskotron but I'm sure they can handle it if they decide to implement this mechanism).

Actually, best tag a few taskotron folks - @tflink @rajcze - so they know about this plan and can chime in on whether they think it's a good idea and whether the design works for the taskotron scheduler.

Contributor

AdamWill commented Sep 1, 2017

@ryanlerch has been volunteered to help with this ;)

So the obvious UI problem for the button is that, right now, all bodhi can know for openQA tests is that it sent the fedmsg requesting the test be rerun. It doesn't know if the test actually got rescheduled, or when it's running, or anything like that. This is also true right now for Taskotron tests - we could fix that using ExecDB, but not in the Javascript.

So for right now I'd suggest we just do a bit of a hack like popping up a 'test rerun requested' notification and hiding the result row. If the user reloads the page they'll see the old result and the 'rerun test' button again, which is unfortunate, but shouldn't have any too grievous consequences (sending multiple 'rerun test' requests won't do anything too terrible at least for openQA, it'll effectively just ignore duplicated requests, I can't speak for Taskotron but I'm sure they can handle it if they decide to implement this mechanism).

Actually, best tag a few taskotron folks - @tflink @rajcze - so they know about this plan and can chime in on whether they think it's a good idea and whether the design works for the taskotron scheduler.

@AdamWill

This comment has been minimized.

Show comment
Hide comment
@AdamWill

AdamWill Sep 1, 2017

Contributor

@pypingou and I were thinking along similar lines about a more sophisticated solution to this problem. There are things other than Bodhi where we might want to put a similar button, e.g. Pagure (for the CI stuff that loops through it). So the idea there would be to have a small web API (ooh, call it a microservice!) which just sends out 'rerun test' requests, with some kind of authentication setup of course (we haven't figured that bit out yet). Then Pagure and Bodhi (and anything else that wanted to do this) could just poke that microservice to send out a test rerun request, instead of each coming up with their own implementation.

We're not sure yet whether it's going to be worth doing this as a short term thing before that gets done; I guess it depends a lot on the time it'll realistically take someone to build that thing. I'm inclining to going ahead with this as the short-term approach for now, but willing to be argued out of it :)

Contributor

AdamWill commented Sep 1, 2017

@pypingou and I were thinking along similar lines about a more sophisticated solution to this problem. There are things other than Bodhi where we might want to put a similar button, e.g. Pagure (for the CI stuff that loops through it). So the idea there would be to have a small web API (ooh, call it a microservice!) which just sends out 'rerun test' requests, with some kind of authentication setup of course (we haven't figured that bit out yet). Then Pagure and Bodhi (and anything else that wanted to do this) could just poke that microservice to send out a test rerun request, instead of each coming up with their own implementation.

We're not sure yet whether it's going to be worth doing this as a short term thing before that gets done; I guess it depends a lot on the time it'll realistically take someone to build that thing. I'm inclining to going ahead with this as the short-term approach for now, but willing to be argued out of it :)

@fedora-infra fedora-infra deleted a comment from centos-ci Sep 6, 2017

@bowlofeggs

Looks good so far! Just a few initial thoughts/suggestions/questions.

scenario = colander.SchemaNode(
colander.String(),
)

This comment has been minimized.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

One more blank line here for PEP-8.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

One more blank line here for PEP-8.

"""
data = request.validated
update = data['update']
test = data['test']

This comment has been minimized.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

Does the test here have any build names or update ids in it, or is it just the generic test name (like "dist.upgradepath")? If the latter, great! If the former, I'll point out that we may want to validate that the test being requested matches the update URL being posted to here.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

Does the test here have any build names or update ids in it, or is it just the generic test name (like "dist.upgradepath")? If the latter, great! If the former, I'll point out that we may want to validate that the test being requested matches the update URL being posted to here.

This comment has been minimized.

@AdamWill

AdamWill Sep 6, 2017

Contributor

I think it's just the test name. That's what I'm expecting it to be, anyhow. We'll find out when I write some tests, I guess...

@AdamWill

AdamWill Sep 6, 2017

Contributor

I think it's just the test name. That's what I'm expecting it to be, anyhow. We'll find out when I write some tests, I guess...

@@ -189,6 +194,36 @@ def set_request(request):
return dict(update=update)
@update_rerun_test.post(schema=bodhi.server.schemas.RerunTestSchema,

This comment has been minimized.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

I think flake8 might get upset about the schema not vertically aligning with the other keys. I suggest moving it to the next line to appease the PEP-8 gods.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

I think flake8 might get upset about the schema not vertically aligning with the other keys. I suggest moving it to the next line to appease the PEP-8 gods.

test = data['test']
scenario = data['scenario']
log.info("Requesting rerun of test %s, scenario %s for update %s",
test, scenario, update)

This comment has been minimized.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

Optional: It might be useful to include the username in this log message. Also optional: consider debug level since the fedmsg itself will also be trackable.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

Optional: It might be useful to include the username in this log message. Also optional: consider debug level since the fedmsg itself will also be trackable.

@@ -138,7 +142,7 @@
'<td>' + icon + '</td>' +
'<td class="nowrap">' + testcase + '</td>' +
'<td class="stretch-table-column text-xs-right">' + note + '</td>' +
'<td class="nowrap">' + age + '</td>' +
'<td class="nowrap">' + age + '</td>' + '<td>' + rerun + '<td/>' +

This comment has been minimized.

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

Like you, I have no idea how to make this work off the top of my head. Let's hope that @ryanlerch can save us!

@bowlofeggs

bowlofeggs Sep 6, 2017

Member

Like you, I have no idea how to make this work off the top of my head. Let's hope that @ryanlerch can save us!

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Sep 11, 2017

Member

I was wondering if we could simply replace this by a simple fedmsg listener that would listen for messages of comment coming from bodhi/pagure/other service and send the re-run message if the message passed some checks (for example: was the person commenting on bodhi one of the maintainer?)

Member

pypingou commented Sep 11, 2017

I was wondering if we could simply replace this by a simple fedmsg listener that would listen for messages of comment coming from bodhi/pagure/other service and send the re-run message if the message passed some checks (for example: was the person commenting on bodhi one of the maintainer?)

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Sep 11, 2017

Member

@pypingou That's not a bad suggestion. We actually have something like that for re-running Bodhi's CI tests on GitHub (I can type "jenkies test" in a comment to trigger re-running the tests. I think even this comment will cause the tests to re-run!)

Member

bowlofeggs commented Sep 11, 2017

@pypingou That's not a bad suggestion. We actually have something like that for re-running Bodhi's CI tests on GitHub (I can type "jenkies test" in a comment to trigger re-running the tests. I think even this comment will cause the tests to re-run!)

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Sep 11, 2017

Member

@AdamWill what do you think?

Also: what should this new service be named? TryAgain? ReRun? There is potential here :)

Member

pypingou commented Sep 11, 2017

@AdamWill what do you think?

Also: what should this new service be named? TryAgain? ReRun? There is potential here :)

@jeremycline

This comment has been minimized.

Show comment
Hide comment
@jeremycline

jeremycline Sep 11, 2017

Member

Personally I think a button is much more intuitive and clear to end users than comment-based triggering.

Member

jeremycline commented Sep 11, 2017

Personally I think a button is much more intuitive and clear to end users than comment-based triggering.

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Sep 11, 2017

Member

The button is more intuitive but much harder to implement considering we want this feature in multiple systems (bodhi, pagure, something else)

Member

pypingou commented Sep 11, 2017

The button is more intuitive but much harder to implement considering we want this feature in multiple systems (bodhi, pagure, something else)

@AdamWill

This comment has been minimized.

Show comment
Hide comment
@AdamWill

AdamWill Sep 11, 2017

Contributor

well, I described my version of the 'do it with a fedmsg microservice' approach above - #1779 (comment) . I kinda prefer that approach (which allows us to build buttons) to a comment-based one, personally. But I mean, if you go away and build the comment based approach and no-one bothers building my design, I'm not gonna stand in your way. :)

Contributor

AdamWill commented Sep 11, 2017

well, I described my version of the 'do it with a fedmsg microservice' approach above - #1779 (comment) . I kinda prefer that approach (which allows us to build buttons) to a comment-based one, personally. But I mean, if you go away and build the comment based approach and no-one bothers building my design, I'm not gonna stand in your way. :)

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Sep 11, 2017

Member

I think I do prefer the button to the comment, but I'm not opposed to the comment. This PR is pretty good so far, we just need some JavaScript :)

Member

bowlofeggs commented Sep 11, 2017

I think I do prefer the button to the comment, but I'm not opposed to the comment. This PR is pretty good so far, we just need some JavaScript :)

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Sep 12, 2017

Member

Alright let's keep the button approach with the simple API on the receiving end to send the fedmsg message.

Also: what should this new service be named? TryAgain? ReRun? There is potential here :)

I'm surprising this crucial question didn't get more attention :)

Member

pypingou commented Sep 12, 2017

Alright let's keep the button approach with the simple API on the receiving end to send the fedmsg message.

Also: what should this new service be named? TryAgain? ReRun? There is potential here :)

I'm surprising this crucial question didn't get more attention :)

@ryanlerch

This comment has been minimized.

Show comment
Hide comment
@ryanlerch

ryanlerch Sep 12, 2017

Contributor

@AdamWill just added a commit to this branch here:
https://github.com/ryanlerch/bodhi/tree/AdamWill/openqa-rerun-button

that does all the hooking up to the interface in JS.

One thing to note here, is that i made the rerun button only show if you have edit privs on the update. Not sure if this was what was intended, but the privs on the serverside would only let me request a rerun if i had edit privs for an update.

Also, after clicking on the icon to request a re-run, it spins just until the request is made, then it stops and a notification is returned to the user saying the request is made.

Feel free to squash this code into a single commit of yours if you wish to too.

Contributor

ryanlerch commented Sep 12, 2017

@AdamWill just added a commit to this branch here:
https://github.com/ryanlerch/bodhi/tree/AdamWill/openqa-rerun-button

that does all the hooking up to the interface in JS.

One thing to note here, is that i made the rerun button only show if you have edit privs on the update. Not sure if this was what was intended, but the privs on the serverside would only let me request a rerun if i had edit privs for an update.

Also, after clicking on the icon to request a re-run, it spins just until the request is made, then it stops and a notification is returned to the user saying the request is made.

Feel free to squash this code into a single commit of yours if you wish to too.

@AdamWill

This comment has been minimized.

Show comment
Hide comment
@AdamWill

AdamWill Sep 12, 2017

Contributor

"One thing to note here, is that i made the rerun button only show if you have edit privs on the update. Not sure if this was what was intended, but the privs on the serverside would only let me request a rerun if i had edit privs for an update."

Yes, this was precisely what I intended - thanks a lot. I can't promise to update this PR immediately as I'm deep in F27 Beta emergencies right now, but I'll try to get to it ASAP.

Contributor

AdamWill commented Sep 12, 2017

"One thing to note here, is that i made the rerun button only show if you have edit privs on the update. Not sure if this was what was intended, but the privs on the serverside would only let me request a rerun if i had edit privs for an update."

Yes, this was precisely what I intended - thanks a lot. I can't promise to update this PR immediately as I'm deep in F27 Beta emergencies right now, but I'll try to get to it ASAP.

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Oct 12, 2017

Member

@AdamWill have you tried out the patch from @ryanlerch? What do you think? Or do we want to wait until we have some common system for asking for tests to be re-run?

Member

bowlofeggs commented Oct 12, 2017

@AdamWill have you tried out the patch from @ryanlerch? What do you think? Or do we want to wait until we have some common system for asking for tests to be re-run?

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Oct 13, 2017

Member

Or do we want to wait until we have some common system for asking for tests to be re-run?

FTR, I'll be starting on this fairly soon :)

Member

pypingou commented Oct 13, 2017

Or do we want to wait until we have some common system for asking for tests to be re-run?

FTR, I'll be starting on this fairly soon :)

@AdamWill

This comment has been minimized.

Show comment
Hide comment
@AdamWill

AdamWill Oct 13, 2017

Contributor

I've been on vacation so haven't had time to look at it. @pypingou, do you have a rough time frame on the common system?

Contributor

AdamWill commented Oct 13, 2017

I've been on vacation so haven't had time to look at it. @pypingou, do you have a rough time frame on the common system?

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Oct 13, 2017

Member

I'm thinking to work on this during the GA freeze which starts next week iirc :)

Member

pypingou commented Oct 13, 2017

I'm thinking to work on this during the GA freeze which starts next week iirc :)

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Oct 18, 2017

Member

@AdamWill Would these messages works for you?

{
  "username": "pingou", 
  "i": 1, 
  "timestamp": 1508340262, 
  "msg_id": "2017-016f241c-ba0f-4ee5-88f6-0dafab90f352", 
  "topic": "org.fedoraproject.dev.rats.test.dist.rpmdeplint", 
  "msg": {
    "test": "dist.rpmdeplint", 
    "identifier": "audit-2.8-1.fc26", 
    "agent": "pingou"
  }
}
{
  "username": "pingou", 
  "i": 1, 
  "timestamp": 1508340715, 
  "msg_id": "2017-67d0226a-0464-4745-9dd6-7e19b8c0e9da", 
  "topic": "org.fedoraproject.dev.rats.test.update.base_selinux", 
  "msg": {
    "test": "update.base_selinux", 
    "identifier": "FEDORA-2017-5e475c0b0d", 
    "agent": "pingou"
  }
}

Note: we can easily make the topic more generic, like: "topic": "org.fedoraproject.dev.rats.test.taskotron", if it's more helpful :)

Member

pypingou commented Oct 18, 2017

@AdamWill Would these messages works for you?

{
  "username": "pingou", 
  "i": 1, 
  "timestamp": 1508340262, 
  "msg_id": "2017-016f241c-ba0f-4ee5-88f6-0dafab90f352", 
  "topic": "org.fedoraproject.dev.rats.test.dist.rpmdeplint", 
  "msg": {
    "test": "dist.rpmdeplint", 
    "identifier": "audit-2.8-1.fc26", 
    "agent": "pingou"
  }
}
{
  "username": "pingou", 
  "i": 1, 
  "timestamp": 1508340715, 
  "msg_id": "2017-67d0226a-0464-4745-9dd6-7e19b8c0e9da", 
  "topic": "org.fedoraproject.dev.rats.test.update.base_selinux", 
  "msg": {
    "test": "update.base_selinux", 
    "identifier": "FEDORA-2017-5e475c0b0d", 
    "agent": "pingou"
  }
}

Note: we can easily make the topic more generic, like: "topic": "org.fedoraproject.dev.rats.test.taskotron", if it's more helpful :)

@rajcze

This comment has been minimized.

Show comment
Hide comment
@rajcze

rajcze Oct 18, 2017

Regarding fedmessages for reruns - I'm just working on something for the execdb/trigger in taskotron stack, and came to the conclusion that fedmessages are the easiest way to communicate between the two (since trigger already listens for those, and lacks any kind of RESTful API).

For the execdb/trigger combo, I have the benefit of knowing precisely how the task at hand was, well, triggered, and which params were passed to the "executor" down the road, so my approach will use those - ExecDB will just take the "this is how we ran it" and feed Trigger a "please run a job with these params" fedmsg. Also ExecDB will have an API endpoint for "hey, rerun this task" (and all Taskotron-related results in resultsdb know the task's UUID), so that could be used from the button in the future, I guess.

The message format for execdb/trigger communication is

{
  "topic": "org.fedoraproject.dev.execdb.task_rerun",
  "msg": {
    "item": "audit-2.8-1.fc26", 
    "item_type": "koji_build",
    "taskname": "rpmlint",
    "arch": "x86_64",
    "uuid": "UUID",
    "__runner__": "BuildotRunner"
  }

Bare in mind that this is not necessarily something you could get from the resultsdb data, so this realisticaly won't be possible to do from Bodhi, but I just wanted to mention that, mostly because of the expected ExecDB feature.

With regards to what can be done for task-rescheduling in the mean time - I'd really like if we had a single topic, with the task name/description in the msg data. On the trigger side, there is a slight issue (that I don't have a great solution for, ATM) with the fact, that the testcase name from resultsdb does not need to (and quite often does not) have any correlation to the internal taskname, which is imperative for the Taskotron stack as it represents the directory/repository in which the formula/scripts/other files are stored. And even if it is similar, it is most likely not the same (e.g. dist.rpmlint testcase vs rpmlint actual taskname).

rajcze commented Oct 18, 2017

Regarding fedmessages for reruns - I'm just working on something for the execdb/trigger in taskotron stack, and came to the conclusion that fedmessages are the easiest way to communicate between the two (since trigger already listens for those, and lacks any kind of RESTful API).

For the execdb/trigger combo, I have the benefit of knowing precisely how the task at hand was, well, triggered, and which params were passed to the "executor" down the road, so my approach will use those - ExecDB will just take the "this is how we ran it" and feed Trigger a "please run a job with these params" fedmsg. Also ExecDB will have an API endpoint for "hey, rerun this task" (and all Taskotron-related results in resultsdb know the task's UUID), so that could be used from the button in the future, I guess.

The message format for execdb/trigger communication is

{
  "topic": "org.fedoraproject.dev.execdb.task_rerun",
  "msg": {
    "item": "audit-2.8-1.fc26", 
    "item_type": "koji_build",
    "taskname": "rpmlint",
    "arch": "x86_64",
    "uuid": "UUID",
    "__runner__": "BuildotRunner"
  }

Bare in mind that this is not necessarily something you could get from the resultsdb data, so this realisticaly won't be possible to do from Bodhi, but I just wanted to mention that, mostly because of the expected ExecDB feature.

With regards to what can be done for task-rescheduling in the mean time - I'd really like if we had a single topic, with the task name/description in the msg data. On the trigger side, there is a slight issue (that I don't have a great solution for, ATM) with the fact, that the testcase name from resultsdb does not need to (and quite often does not) have any correlation to the internal taskname, which is imperative for the Taskotron stack as it represents the directory/repository in which the formula/scripts/other files are stored. And even if it is similar, it is most likely not the same (e.g. dist.rpmlint testcase vs rpmlint actual taskname).

@AdamWill

This comment has been minimized.

Show comment
Hide comment
@AdamWill

AdamWill Oct 18, 2017

Contributor

Half-baked idea: just include the resultsdb ID of the result the re-run was requested for, and let the scheduler look the result up in resultsdb and use all the data there to figure out how to 're-run' that test? I'm not sure how else we can make this work across multiple systems...

Contributor

AdamWill commented Oct 18, 2017

Half-baked idea: just include the resultsdb ID of the result the re-run was requested for, and let the scheduler look the result up in resultsdb and use all the data there to figure out how to 're-run' that test? I'm not sure how else we can make this work across multiple systems...

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Oct 19, 2017

Member

I've added an extras field to rats' API which can contain any information that are then just passed onto the fedmsg message. So any 'extra' information one would want to be present in the fedmsg messages sent by rats could be added there :)

I'm going to work on tests and documentation today so I have something to show later :)

Member

pypingou commented Oct 19, 2017

I've added an extras field to rats' API which can contain any information that are then just passed onto the fedmsg message. So any 'extra' information one would want to be present in the fedmsg messages sent by rats could be added there :)

I'm going to work on tests and documentation today so I have something to show later :)

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Oct 19, 2017

Member

Alright, I got the basis set, still needs some work (also because it'll require changes to flask-oidc) but it should give us an idea of whether we like it or not.

There it is: https://pagure.io/rats

Member

pypingou commented Oct 19, 2017

Alright, I got the basis set, still needs some work (also because it'll require changes to flask-oidc) but it should give us an idea of whether we like it or not.

There it is: https://pagure.io/rats

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Dec 6, 2017

Member

@pypingou @AdamWill So what's the status on this PR? Are we waiting on me? :)

Member

bowlofeggs commented Dec 6, 2017

@pypingou @AdamWill So what's the status on this PR? Are we waiting on me? :)

@AdamWill

This comment has been minimized.

Show comment
Hide comment
@AdamWill

AdamWill Dec 11, 2017

Contributor

My status is "I haven't really had time to follow up on @pypingou 's work here". I think @pypingou is waiting on feedback from the rest of us, possibly.

Contributor

AdamWill commented Dec 11, 2017

My status is "I haven't really had time to follow up on @pypingou 's work here". I think @pypingou is waiting on feedback from the rest of us, possibly.

@pypingou

This comment has been minimized.

Show comment
Hide comment
@pypingou

pypingou Dec 12, 2017

Member

@AdamWill that and I was waiting for a feature to be added to flask-oidc to finish another piece of it.
That feature has now been added so I'll likely be working on finishing up that work next week

Member

pypingou commented Dec 12, 2017

@AdamWill that and I was waiting for a feature to be added to flask-oidc to finish another piece of it.
That feature has now been added so I'll likely be working on finishing up that work next week

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Mar 8, 2018

Member

Do we want to keep this PR open?

Member

bowlofeggs commented Mar 8, 2018

Do we want to keep this PR open?

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Mar 15, 2018

Member

I'm going to close this PR for now. Feel free to reopen if you want to proceed!

Member

bowlofeggs commented Mar 15, 2018

I'm going to close this PR for now. Feel free to reopen if you want to proceed!

@bowlofeggs bowlofeggs closed this Mar 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment