Open travi opened 10 months ago
This issue is stale because it has been open for 60 days with no activity.
This issue is stale because it has been open for 60 days with no activity.
(apologies for the multiple stale comments, we changed the label so it re-triggered for the new label)
It would be really helpful if the reusable workflow definitions could be evaluated and result in similar evaluation of checks like this.
So one problem with re-usable workflows is the need to go and fetch the contents for analysis. Which could be done with another API call, just a lot of our existing workflow-analysis code assumes all the files needed are in the same repo.
One thing we're working on in 2024 is a Scorecard file for maintainers to explain these sort of situations, where the repo is doing a certain behavior but we're not detecting it.
This issue has been marked stale because it has been open for 60 days with no activity.
i recognize that a javascript implementation isnt directly helpful in this project, but i had a colleague introduce me to https://github.com/actions/languageservices/tree/main/workflow-parser recently and explained that it can be used to not only parse the workflow file, but also render the more complete picture, like the use of reusable workflows. because of that, it seemed worth at least capturing here in case it could at least serve as a reference
Is your feature request related to a problem? Please describe.
As mentioned in my PR to add semantic-release support, I primarily make releases though a reusable workflow because the release steps are so consistent across projects. While the addition of semantic-release support has been great for our community members who release directly from their base workflow definition, recognition is missed when reusable workflows are used to encapsulate the use of semantic-release.
Describe the solution you'd like
It would be really helpful if the reusable workflow definitions could be evaluated and result in similar evaluation of checks like this.
Describe alternatives you've considered
In the semantic-release org, we've chosen to continue defining the release steps directly in our base workflow files, but have continued to discuss the potential for drift and the other downsides of defining the same steps in several projects.
Additional context