With this change, details about a workspace and worker are saved as an event when they are posted to the server. The intention of this is to make it a little easier to see what activity was run in check vs run mode in the event history.
I took this approach as just a quick fix, but I think with more effort it could probably be improved. The WorkspaceEvent model doesn't have a field for command or mode, and certainly not all events are directly associated with with those notions. So it didn't make sense to me to add this to the model; WorkspaceEvents have an intentionally simple scheme that's "generally useful" for a wide variety of cases. An improvement that I think could be made upon this change would be for the CLI to post messages in a way that clearly details the subcommand associated with the event, but I figured this change would be a good start.
A known issue with this change is that the events table in the UI only stores 64 events (currently) and this new internal event will get cut off at the bottom sometimes. The internally generated event will still be available in the application log, however.
Along with this change I added a common function to emit internal events, and I've also updated another area where we're generating internal event to use this new function.
How was this tested?
Tested locally
Checklist
[x] Have you updated the VERSION file (if applicable)?
What and why?
This is a minimally viable approach to fix #6
With this change, details about a workspace and worker are saved as an event when they are posted to the server. The intention of this is to make it a little easier to see what activity was run in check vs run mode in the event history.
I took this approach as just a quick fix, but I think with more effort it could probably be improved. The WorkspaceEvent model doesn't have a field for
commandormode, and certainly not all events are directly associated with with those notions. So it didn't make sense to me to add this to the model; WorkspaceEvents have an intentionally simple scheme that's "generally useful" for a wide variety of cases. An improvement that I think could be made upon this change would be for the CLI to post messages in a way that clearly details the subcommand associated with the event, but I figured this change would be a good start.A known issue with this change is that the events table in the UI only stores 64 events (currently) and this new internal event will get cut off at the bottom sometimes. The internally generated event will still be available in the application log, however.
Along with this change I added a common function to emit internal events, and I've also updated another area where we're generating internal event to use this new function.
How was this tested?
Tested locally
Checklist