You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, with reusable workflows being a thing, where one might want to centralize some of the common configurations in a .github repository, this doesn't work, unless the config is in the target repo, rather than the reusable repository.
Below is an example workflow, that is a reusable workflow, and it clones my personal lrstanley/.github repository, where most of my triage-related configuration files are stored. I'd like to be able to read from that repo.
Most actions I've used so far (esp. relating to labeling), will read from a local file for the configuration. It would be nice if this action could support first trying to see if $PWD/<configuration-path> exists, and if not, falling back to using the content API.
The text was updated successfully, but these errors were encountered:
Looks as though the action is currently hardcoded to use the API to pull the configuration file, as shown below:
issue-labeler/src/main.ts
Lines 133 to 138 in 772f647
However, with
reusable
workflows being a thing, where one might want to centralize some of the common configurations in a.github
repository, this doesn't work, unless the config is in the target repo, rather than the reusable repository.Below is an example workflow, that is a reusable workflow, and it clones my personal
lrstanley/.github
repository, where most of my triage-related configuration files are stored. I'd like to be able to read from that repo.Most actions I've used so far (esp. relating to labeling), will read from a local file for the configuration. It would be nice if this action could support first trying to see if
$PWD/<configuration-path>
exists, and if not, falling back to using the content API.The text was updated successfully, but these errors were encountered: