Add workflow events

[Leo10Gama]

Which issue(s) does this change fix?

N/A

Why is this change necessary?

Events previously exist to capture the runtime of functions as they are built. However, up until now, we do not have a way to capture the information of workflow configs.

How does it address the issue?

With a new WorkflowUsed Event, we will be able to capture and analyze data on which workflows customers are using most. This can reveal information such as the most common languages of workflows, most common dependency managers, and how many different workflow configs are used per build.

What side effects does this change have?

A new file, workflows.py, has been created to prevent a cyclic import, and allow for dynamic computing of Event values. Thus, for any new workflow to be added, it would need to be created there, and then be imported by workflow_config.py.

Mandatory Checklist

PRs will only be reviewed after checklist is complete

• Add input/output type hints to new functions/methods
• Write design document if needed (Do I need to write a design document?)
• Write/update unit tests
• Write/update integration tests
• Write/update functional tests if needed
• make pr passes
• make update-reproducible-reqs if dependencies were changed
• Write documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mildaniel]

Looks good overall,left some minor comments. Can we also add some tests here to validate this functionality?

[Leo10Gama]

Can we also add some tests here to validate this functionality?

I'm not sure whether tests would be necessary for a change like this. I intentionally designed the EventTracker to be lightweight, such that Events could be tracked quickly with only a line or two of code, and able to be removed just as quickly. My line of logic is, if in the future we didn't need this information and wanted to remove the tracker, we'd also have to dig through tests and remove the relevant ones to allow make pr to pass. I think it should be enough that the trackers are verified locally through a dummy project or two to ensure their logic is correct, though I could implement tests to verify this if we really wanted to be sure.

[mildaniel]

I would generally disagree that the ability to make lightweight changes quickly is a reason against testing. If someone accidentally removes this logic in the future, they might think it's okay because all of the tests still pass. Not everyone has and will have the same context. For that reason, I think having tests as a guardrail against regression is already more valuable than the couple extra minutes someone will need to spend to remove a few tests later on.