Show Run#metadata in the web UI

[shouichi]

As the example in the README, a common use case of metadata is to record who ran the task. By displaying metadata in the web UI, we can know who ran the task at a glance.

[nvasilevski]

Rendering metadata seems absolutely reasonable to me! But I wonder if we should still try to define two separate partials for arguments & metadata so applications have the opportunity to override them independently.
We could still have the default one called _serializable but I wonder if we should define _arguments and _metadata which will render _serializable by default but allow applications to customize them independently

@adrianna-chang-shopify @etiennebarrie would love to hear your opinions!

[adrianna-chang-shopify]

I would prefer separate partials 👍

[shouichi]

Thank you for the review! I adjusted the partials based on the feedback.

[etiennebarrie]

One issue I see is that we can't really assume metadata is a Hash. We serialize JSON so it could be a Hash, an Array, a String, or a Numeric. To test this:

diff --git i/test/dummy/config/application.rb w/test/dummy/config/application.rb
index 4f864e4..f5d023f 100644
--- i/test/dummy/config/application.rb
+++ w/test/dummy/config/application.rb
@@ -19,6 +19,7 @@ class Application < Rails::Application
 
     config.to_prepare do
       MaintenanceTasks.job = "CustomTaskJob"
+      MaintenanceTasks.metadata = -> { "foo" }
     end
 
     # Only include the helper module which match the name of the controller.

[shouichi]

Thank you for pointing it out! I didn't realize that.

Because a JSON can have arbitrary structure and displaying it nicely can be tricky. Can we simply dump JSON in the <code> tag?

[etiennebarrie]

Maybe we could support both immediate values like strings, numbers, true and false, and complex values like objects and arrays. Let's do the minimum thing like if it's a hash, show the fields separately, otherwise just an inspect.

And to be confirmed, but we should see if it's easy to override the partial if needed, that way any more complex scenarios can be handled by the developers of the app by implementing the partial?

[shouichi]

Maybe we could support both immediate values like strings, numbers, true and false, and complex values like objects and arrays. Let's do the minimum thing like if it's a hash, show the fields separately, otherwise just an inspect.

Done. Could you take a look?

[nvasilevski]

thank you! No concerns from my side

Let's wait for @etiennebarrie's opinion

[etiennebarrie]

It works great. I tried and we can indeed override the partial if needed:

diff --git c/test/dummy/app/views/maintenance_tasks/runs/_metadata.html.erb i/test/dummy/app/views/maintenance_tasks/runs/_metadata.html.erb
new file mode 100644
index 0000000..8d293b6
--- /dev/null
+++ i/test/dummy/app/views/maintenance_tasks/runs/_metadata.html.erb
@@ -0,0 +1,3 @@
+<% if metadata.present? %>
+  <p>Started by <%= metadata %></p>
+<% end %>
diff --git c/test/dummy/config/application.rb i/test/dummy/config/application.rb
index 4f864e4..14291df 100644
--- c/test/dummy/config/application.rb
+++ i/test/dummy/config/application.rb
@@ -19,6 +19,7 @@ class Application < Rails::Application
 
     config.to_prepare do
       MaintenanceTasks.job = "CustomTaskJob"
+      MaintenanceTasks.metadata = -> { "Étienne Barrié" }
     end
 
     # Only include the helper module which match the name of the controller.

To get:

Maybe it's worth documenting, but maybe it's better not to.

We already have maintenance_tasks/tasks/custom and maintenance_tasks/runs/info/custom that can be overriden but were not documented.

In any case, the feature out of the box is useful, thanks for your contribution!