Improve error messaging on CLI by specifying job names/edges in error messages about lightning

[josephjclark]

Hey @christad92 turns out that this is actually a Lightning issue. The error strings are coming from the Lightning backend

I've tightened up a few things in CLI deploy and i's been worth checking, but I'm going to have to hand this one over to a grown up now

[josephjclark]

@midigofrank This isn't so much about missing names

Lightning is already running a bunch of validation in lib/lightning/workflows/job.ex :: validate(). Stuff like checking what characters are in the name string, ensuring an adaptor is set.

We just need to append some kind of pathing information into the message.

Maybe check this slack thread for a bit more context

[ritazagoni]

This is also impacting debugging GH sync failures of existing projects on app

[josephjclark]

Hi @ritazagoni - I've been meaning to get to this all week. It's sort of been second on my list every day 😬

I think it's an easy fix, I'll get on it

[midigofrank]

@josephjclark will the cli still make a request to the server if the workflow and job names are missing from the yaml?
Without the names in the params, the backend won't be quite helpful either 😬 .

If they're editing an existing workflow/job, then yes, but for a new workflow / job, I don't see a way

[midigofrank]

@christad92 I haven't been able to format the error messages as in the description. What I have been able to do is group the error messages based on the workflow/job/trigger/edge name. For example:
Previous

{
  "errors": {
    "workflows": [
      {
        "jobs": [
          {
            "body": ["Code editor cannot be empty."]
          }
        ]
      }
    ]
  }
}

---

NOW:

{
  "errors": {
    "workflows": {
      "workflow-one": {
        "jobs": {
          "first-job": {
            "body": ["Code editor cannot be empty."]
          }
        }
      }
    }
  }
}

Can this suffice?

[midigofrank]

As for edges, the key will be source_job->target_job as it is in the yaml file

[josephjclark]

@midigofrank I think this will be fine. I'll try and test against this against your branch and comment in the PR