search

githubtraining / looking-glass-action

provides feedback to learners based on the outcome of their validation lab grader workflow
MIT License
35 stars 10 forks source link

Feature Request: Define Looking Glass payload signature #3

Closed mattdavis0351 closed 3 years ago

mattdavis0351 commented 3 years ago

Is your feature request related to a problem? Please describe.

The current payload that Looking Glass expects is undocumented and is also very limiting. If we want this to be the flagship feedback mechanism for hands-on labs we need to make this signature more robust and flexible for validation action authors.

Describe the solution you'd like

Design a scalable signature that can adapt to platform changes as well as a variety of content.

Describe alternatives you've considered

This is the whole point of Looking Glass... there are no alternatives

Additional context

They current payload signature is as follows:

{
    type: <string: issues, actions>,
    level: <string: info, warning, fatal>,
    msg: <string>
}

The current source code for looking glass is not even able to support all of these options. For example, the level was included to decide the level of logging for use with GitHub Actions if that is the desired feedback type. This may or may not be a field we want to keep in the long run for the Looking Glass.

The level could also be used to determine what tags get applied to an issue, if any, based on what a validation/troubleshooting action thinks the best way to display feedback is.

Using a level may not even be the right course of action for the Looking Glass.

Currently, the Looking Glass cannot handle things like Pull Requests or Project Boards and other ways of providing feedback in a GitHub repository. This is a must for Looking Glass maturity.

mattdavis0351 commented 3 years ago

This definition was addressed in #9

Implementation is being addressed in