Skip to content

Support inline definition or remote reference of the config-file #30

@alombarte

Description

@alombarte

Hi,

Thank you for creating and maintaining this action. I am opening a feature request because I think it would be very useful to manage labels from all repositories in an organization by allowing the configuration file to be centralized (or maybe I am just not seeing something, and it is already possible).

I've tried the action for a single repository, and it works awesome. Then, I wanted to set this action at an organizational level (in the special type .github repository - not folder - ) and reuse it across many repositories to define the (massive) configuration file only once. Today, the configuration is not declared inline in the same workflow but in a configurable external file. However, the external configuration file is always assumed to live inside the repository whose job is calling the action. While I can centralize the action with an on.workflow_call it seems I cannot centralize its configuration.

I understand that I can copy and paste the configuration file across all my organization repositories, but I thought that if the configuration file could be loaded externally or, more simply, defined inline in the same workflow YML, it would be very useful to reuse it everywhere.

I understand there is no way to specify a remote configuration file, so this feature request would allow this:

On a shared repository that contains all label actions defined, like https://github.com/orgname/.github:

# file git/orgname/.github/.github/workflows/label-actions.yml
name: 'Label Actions'
on:
  workflow_call:
...
jobs:
  action:
    runs-on: ubuntu-latest
    steps:
      - uses: dessant/label-actions@v4
        with:
          # resolve against an external repo
          config-path: https://github.com/orgname/.github/.github/label-actions.yml@main

And then all repos wanting to use this action would simply call it like this:

name: 'Label Actions'
on:
  issues:
    types: [labeled, unlabeled]

permissions:
  contents: read
  issues: write

jobs:
  labels:
    uses: orgname/.github/.github/workflows/label-actions.yml@main

Would that make sense?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions