Create a web front-end for running recipes

[ahal]

It would be nice to run recipes from the web in addition to a CLI. This issue will just tackle creating a basic flask app that can be run locally (and not standing up a server or anything just yet).

Let's start with something basic and we can add more features later on as we go.

[nadaa]

Hi @ahal, I can work on this but I need to know how the front-end will look like?

[ahal]

Hey @nadaa, this one will be a lot more difficult than the other ones (I was planning to eventually get something basic working that we could use as a starting point), but if you are up for a challenge you are welcome to try it!

Have you ever created a flask app before? I wouldn't worry about the looks at first. Just a blank page with a bunch of links (one link per recipe). When you click on the link, the recipe should run and then there should be a little area that displays the result in table form. Once that is working we can worry about making it look nicer.

[nadaa]

Hi @ahal, I have some background in flask, I have some experience in APIs. I will give it a try and let you know. Thank you.

[nadaa]

this is the start

[ahal]

Nice, that was quick! Yeah that's a great start. So next you'll need to hook up the link trigger to run the recipe and display a table somewhere. I'd recommend using the --format=markdown argument and then run it through a markdown parser (e.g python-markdown) to convert the result to an HTML table.

[nadaa]

[nadaa]

I will try to make it nicer. Also, some recipes don't work.

[nadaa]

@ahal, what do you think?

[nadaa]

These recipes don't work:

backout_rate code_coverage code_coveage_by_suite file_with_coverage (empty) intermittent_tests intermittent_test_data raw_coverage test_config_times test_effciency try_usage try_users (empty)

[ahal]

Awesome, this is great! I'm a fan of working in small increments, so if you want to put up a PR we can start working on the review and getting what you have landed so far. So this next part is meant as follow-up work (after what you have here is merged). Assuming you're still interested :)

Next we'll need to figure out how we can specify the recipe arguments (e.g the task_durations takes a --branch argument). In the long run, I'd like the arguments a recipe uses to be defined in a more structured manner (right now it's just using argparse which will be hard to extract information from). I'd love if the web app could automatically read the arguments that a recipe uses and then create a form (with defaults) from that. But this will require a lot of refactoring on the backend (which I was planning to do sometime in the next week or two).

In the short term, it would be easier to just provide a blank input box where users can type in the arguments (which we then pass on to the recipe wholesale). In order to support this, we'll probably have to move to a recipe per page.

So I'd keep your landing page that lists all recipes as links. But when you click the clink, it would take you to a new page specific to that recipe. This new page would contain a form (whose submit button runs the recipe). For now the form would be single text box that allows the user to specify additional arguments as a string.

[nadaa]

Hi @ahal, I see what you mean, and I'll investigate more on this. I also like your simplicity approach :).

Do users know what arguments associated with each recipe? Maybe we can put textbox with a label for each argument.!

[ahal]

Some user's might know the arguments by heart if they run the recipe frequently, but for the most part they probably won't have it memorized.

Putting in help labels is a good idea, but I want to avoid hard coding this into the web app. Ideally I'd like the webapp to be able to extract help information about the arguments from the recipes themselves. Unfortunately it isn't currently that easy to do that at the moment, it'll require some changes to the format of the recipes themselves.

[mesumbejoan]

Hello, Is it Ok if I work on some further improvement of the UI? @ahal @nadaa

[ahal]

Hi @mesumbejoan, the relevant PR hasn't landed yet, so even though you could technically pull in @nadaa's changes and base your work on top of those, your changes would almost certainly be repeatedly broken as nothing is set in stone yet.

I'd suggest you wait for @nadaa to finish this PR, then we can figure out a good way to break up work between the two of you so that you aren't conflicting with one another. In the meantime we can find something else for you to work on.

[mesumbejoan]

@ahal Thanks for the feedback, I would love it if we find something else for me to work on. Please let me know what you suggest I do.

THanks

[ahal]

@nadaa thanks for your contribution!

@mesumbejoan now that this is landed I think I can try to split out new work into different issues. Give me a bit and I'll file some issues once I've thought through it some more. Keep an eye out for other new issues too.

[nadaa]

@ahal, it is my pleasure, thanks for your ongoing guidance! @mesumbejoan, good luck :)