Simpler structure for configuration.

[Ferroin]

Description:

Instead of requiring every single level of keys below the top level in the configuration file to have a list as a value, restructure to use mappings whenever possible.

In effect, change the config structure so that the following:

some_label:
  - any:
      - changed-files:
          - any-glob-to-any-file:
              - pattern1
              - pattern2
  - all:
      - head-branches:
          - pattern3
      - base-branches:
          - pattern4

instead is represented like this:

some_label:
  any:
    changed-files:
      any-glob-to-any-file:
        - pattern1
        - pattern2
  all:
      head-branches:
        - pattern3
      base-branches:
        - pattern4

Justification:

The config format used in v4 utilized type based discrimination of the list items for each label in the config to maintain backwards compatibility despite the addition of the all and any syntax. I would argue that requiring a list in this case was less than ideal (JS/TS should be able to easily differentiate between an array and an object, and that type of differentiation would have made the config a bit easier to understand logically), but the backwards compatibility aspect was useful because the new config parser still supported the old format.

With v5 though, this habit of making value under each label be a list of objects or strings was kept and further propagated to the new ‘sub’ configuration items, despite the fact that the new config format is not at all backwards compatible with the old formats.

This has a number of distinct disadvantages for end users:

• The resultant config files include excess boilerplate structure that do not contribute anything to the actual meaning of the configuration, opening up significant possibility of confusion on the part of users who are trying to understand (or write) a given configuration.
• This format is at best rather difficult to write an accurate schema for, if not outright impossible depending on how pedantic you want to be. This makes it harder for users to validate the config file before committing it or before merging changes to it, which is particularly significant because the normal usage of this action as a pull_request_target hook instead of a pull_request hook means that an invalid config file won’t actually show any errors until after it’s merged, at which point it will fail workflow runs on unrelated PRs.

I also strongly suspect that the code doing the parsing is, in fact, more complex than it would need to be if this proposal were implemented, so this may have long-term benefits for the maintainability of the code.

Are you willing to submit a PR?

Unfortunately not, as I have no background working with TypeScript and recognize that this will probably require some nontrivial changes to the code that parses the config file.

[MaksimZhukov]

Hello @Ferroin ! Thank you!
We will consider implementing this feature and will contact you as soon as we have any updates!

[akramaglan20]

وصف:

بدلاً من مطالبة كل مستوى من المفاتيح الموجودة أسفل المستوى الأعلى في ملف التكوين بالحصول على قائمة كقيمة، قم بإعادة الهيكلة لاستخدام التعيينات كلما أمكن ذلك.

في الواقع، قم بتغيير بنية التكوين بحيث يكون ما يلي:

some_label:
  - any:
      - changed-files:
          - any-glob-to-any-file:
              - pattern1
              - pattern2
  - all:
      - head-branches:
          - pattern3
      - base-branches:
          - pattern4

بدلا من ذلك يتم تمثيله مثل هذا:

some_label:
  any:
    changed-files:
      any-glob-to-any-file:
        - pattern1
        - pattern2
  all:
      head-branches:
        - pattern3
      base-branches:
        - pattern4

التبرير:

استخدم تنسيق التكوين المستخدم في الإصدار 4 التمييز القائم على النوع لعناصر القائمة لكل تسمية في التكوين للحفاظ على التوافق مع الإصدارات السابقة على الرغم من إضافة وبناء allالجملة any. أود أن أزعم أن طلب القائمة في هذه الحالة كان أقل من مثالي (يجب أن يكون JS/TS قادرًا على التمييز بسهولة بين المصفوفة والكائن، وهذا النوع من التمايز كان من شأنه أن يجعل التكوين أسهل قليلًا للفهم منطقيًا)، ولكن كان جانب التوافق مع الإصدارات السابقة مفيدًا لأن محلل التكوين الجديد لا يزال يدعم التنسيق القديم .

مع الإصدار 5، تم الاحتفاظ بهذه العادة المتمثلة في جعل القيمة تحت كل تسمية عبارة عن قائمة من الكائنات أو السلاسل وتم نشرها بشكل أكبر إلى عناصر التكوين "الفرعية" الجديدة، على الرغم من حقيقة أن تنسيق التكوين الجديد غير متوافق على الإطلاق مع التنسيق القديم التنسيقات.

وهذا له عدد من العيوب المميزة للمستخدمين النهائيين:

• تتضمن ملفات التكوين الناتجة بنية معيارية زائدة لا تساهم بأي شيء في المعنى الفعلي للتكوين، مما يفتح احتمالًا كبيرًا للارتباك من جانب المستخدمين الذين يحاولون فهم (أو كتابة) تكوين معين.
• يعد هذا التنسيق في أحسن الأحوال أمرًا صعبًا إلى حد ما لكتابة مخطط دقيق له، إن لم يكن مستحيلًا تمامًا اعتمادًا على مدى التحذلق الذي تريده. وهذا يجعل من الصعب على المستخدمين التحقق من صحة ملف التكوين قبل تنفيذه أو قبل دمج التغييرات فيه، وهو أمر مهم بشكل خاص لأن الاستخدام العادي لهذا الإجراء كربط بدلاً من pull_request_targetربط pull_requestيعني أن ملف التكوين غير الصالح لن يظهر فعليًا أي أخطاء حتى بعد دمجها، وعند هذه النقطة سيفشل تشغيل سير العمل على المستفيدين الرئيسيين غير المرتبطين.

كما أشك بشدة في أن الكود الذي يقوم بالتحليل هو في الواقع أكثر تعقيدًا مما قد يلزم إذا تم تنفيذ هذا الاقتراح، لذلك قد يكون لهذا فوائد طويلة المدى لقابلية صيانة الكود.

هل أنت على استعداد لتقديم العلاقات العامة؟

لسوء الحظ لا، حيث ليس لدي أي خلفية في العمل باستخدام TypeScript وأدرك أن هذا سيتطلب على الأرجح بعض التغييرات البسيطة على الكود الذي يوزع ملف التكوين.
some_label:
any:
changed-files:
any-glob-to-any-file:
- pattern1
- pattern2
all:
head-branches:
- pattern3
base-branches:
- pattern4

[akramaglan20]

some_label:
any:
changed-files:
any-glob-to-any-file:
- pattern1
- pattern2
all:
head-branches:
- pattern3
base-branches:
- pattern4

[akramaglan20]

some_label:
any:
changed-files:
any-glob-to-any-file:
- pattern1
- pattern2
all:
head-branches:
- pattern3
base-branches:
- pattern4

[rbiersbach]

First of all thanks for creating and maintaining this awesome github action!
I know this is not super constructive feedback, but I stopped the upgrade from 4.0 to 5.0 after 20 min of trying to understand the new structure of the config.
I am just maintaining the action somebody else created and couldn't figure out what the new structure means.
Maybe it is a matter of updating the docs ( that I read ) but I thought you should be aware and it adds to this feature request.

The config I wanted to update:

frontend: static/**/*.js
backend: src/**/*.py
github_actions: .github/**/*
db_migration: '**/migrations/**'

missing_fe_tests:
  - any: [ 'static/**/*.js' ]
    all: [ '!static/**/*.test.js' ]
missing_be_tests:
  - any: [ 'src/**/*.py', '!**/migrations/**', '!src/**/admin.py' ]
    all: [ '!**/tests/**' ]
missing_email_tests:
  - any: [ 'mjml_email_templates/src/**' ]
    all: [ '!mjml_email_templates/src/__tests__/*.test.js' ]

[QuLogic]

This format is at best rather difficult to write an accurate schema for, if not outright impossible depending on how pedantic you want to be. This makes it harder for users to validate the config file before committing it or before merging changes to it, which is particularly significant because the normal usage of this action as a pull_request_target hook instead of a pull_request hook means that an invalid config file won’t actually show any errors until after it’s merged, at which point it will fail workflow runs on unrelated PRs.

I can't say whether it works perfectly or not, but I wrote an updated schema that's available on JSON Schema Store: https://json.schemastore.org/pull-request-labeler-5.json

[StarpTech]

I know this is not super constructive feedback, but I stopped the upgrade from 4.0 to 5.0 after 20 min of trying to understand the new structure of the config.

Same for me. I also see

The configuration file (path: .github/labeler.yml) was not found locally, fetching via the api

[dieter-aerit]

I just upgraded to v5, saw that it was a breaking change and came here to see what the update is about.
I can also say that I think the config format feels pretty over-engineered.

Especially this:

• any-glob-to-any-file: ANY glob must match against ANY changed file
• any-glob-to-all-files: ANY glob must match against ALL changed files
• all-globs-to-any-file: ALL globs must match against ANY changed file
• all-globs-to-all-files: ALL globs must match against ALL changed files

I mean yes it's super flexible, but I had to read this 5 times to understand what it's about and I have a hard time coming up with use-cases for it. I think I'll use 'any-glob-to-any-file' 99% of the time (cfr. old config).

It's a bit sad and short-sighted that this complexity and verbose config file format is forced upon all users for some pretty niche use-cases.
It would be nice if this functionality was integrated in a way where the main use-cases stay simple, but the functionality is available for power-users who want it (without putting the complexity on everyone).

I definitely don't need this complexity and see it only as a nuisance. If there was a version of the action with v4 config file syntax but upgraded to node 20 I'd be using that for sure.
For non-critical functionality like this, simple is better. Nobody wants to parse and memorise a custom DSL language for every tiny tool you're using. Please keep it simple.

I guess I'm off copy-pasting the following a few hundred times in all our labeler config files now 🙄 :

  - changed-files:
      - any-glob-to-any-file:

Update:
After messing around for 15m and not getting past the below error, even though the syntax is identical to the README, I'm going to simply revert to v4 and ignore the node error. This is not worth it for me.
Error: found unexpected type for label 'github' (should be array of config options)

Update 2:
I guess the labeler is using the config file from the main branch, so I would have to iterate by trial-and-error and commit to main to figure out the correct syntax. Making this change a magnitude more annoying.
Definitely not worth it for me sorry.