feat: Create Github Actions to auto manage some labels

[davorpa]

It will be great that when a PR is merged doing some actions

How to handle it: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-workflow-when-a-pull-request-merges

pr-merged.yml:

on:
  pull_request:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

Then we need:

1. Is this usefull?
2. Decide which labels manage. E.g.: remove Waiting for changes, stale...
3. ...

[LuigiImVector]

Interesting but I find it a bit useless, it would be better to have a bot that could fully handle labels:

• auto language file label (-it, -en, -es...)
• auto stale (after x days)
• auto conflics
• ...

[davorpa]

• auto language file label (-it, -en, -es...)

I've found two ways of get files of PR:

• With GH cli: gh pr view XXXX --json files -q '.files[].path' where XXXX is the PR number
• With an action tj-actions/changed-files as composite step

or actions/labeler as full separate action

@LuigiImVector what will be better seen your progress with actions in the past (linter, url-check)?

[LuigiImVector]

@LuigiImVector what will be better seen your progress with actions in the past (linter, url-check)?

We can also use trilom/file-changes-action, implemented earlier on check-urls.yml but I think tj-actions/changed-files is just fine.

EDIT
Alternatively, we can use Probot (proposed on #7053) using https://probot.github.io/apps/boring-cyborg/ (very similar to actions/labeler).

[davorpa]

Due to amount of labels it will be great have some process to automate label syncing using a file as source. Forks will have the label config synced too

Then collaborators could add new labels as part of code, eg. when new locale appears, on new workflow demand...

An example will be use this action: https://github.com/crazy-max/ghaction-github-labeler in a workflow called sync-labels.yml

[eshellman]

I have not found the language labels to be useful. They make it a chore to applied labels at the bottom of the list and are hard to read for my older eyes. Maybe a better way to approach it is to have an action that adds a language notation to the PR title.

[nbehrnd]

A pattern applied in learnxinyminutes is [language/lang-code], e.g. [awk-fr] (example). A priori this should equally apply when filing a PR for a new entry, or revising an already existing entry. On occasion, the marker of the natural language is split into locales (like pt-pt, and pt-br).

For English contributions, the file eventually deposit doesn't mention the language explicitly. In this perspective, the name of the markdown file about Fortran90 is read with some irony (because of the then introduced standard safe guard of implicit none...)

[eshellman]

that's a great example!

[davorpa]

About the autoconflicts workflow.

We can use:

the GH client:

gh api repos/EbookFoundation/free-programming-books/pulls/NNNN --jq '{mergeable, mergeable_state, number, title}'

where NNNN is the prNumber.

• mergeable: The value of the mergeable attribute can be true, false, or null. If the value is null, this means that the mergeability hasn’t been computed yet, and a background job was started to compute it. Give the job a few moments to complete, and then submit the request again. When the job is complete, the response will include a non-null value for the mergeable attribute.
• mergeable_state: gives a little more info with the values of clean, dirty, blocked, unstable, or unknown. It seems like dirty means merge conflicts, clean if not

One of these actions:

• https://github.com/eps1lon/actions-label-merge-conflict
• https://github.com/mschilde/auto-label-merge-conflicts

Other usefull action to detect potential conflicts even if not yet merged (usefull to mantainers to merge following an order):

• https://github.com/outsideris/potential-conflicts-checker-action

[eshellman]

the improvements to linter label management have been invaluable!