fix(ci): err due to update-node-dist being canceled

[max-nextcloud]

The update-node-dist workflow pushes a new commit to the branch it runs on.
This commit triggers the workflow again.
Prevent the second workflow from canceling the first
just before the first would have finished.

Every time the workflow is canceled it sends out a notification.

Without cancel-in-progress there will be at most one workflow running and one pending.
Most of the time the pending workflow will be the one that resulted from the commit pushed by the running workflow.
If two PRs are merged quickly after each other
first run will be finished even though it was not needed.
However this will happen rarely and will at most waste a few minutes of CI runtime.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 46.76%. Comparing base (702ef89) to head (92da92f).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6801   +/-   ##
=======================================
  Coverage   46.76%   46.76%           
=======================================
  Files         748      748           
  Lines       34163    34163           
  Branches     1242     1242           
=======================================
  Hits        15976    15976           
  Misses      17565    17565           
  Partials      622      622           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mejo-]

Mhh, I'm not sure whether this is the right approach. If your assumption is correct, that the commit by update-node-dist triggers the workflow again, then removing cancel-in-progress would mean an endless chain of actions being activated by a merge, no?

I wonder whether something like https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#running-your-pull_request_target-workflow-when-a-pull-request-merges would be better.

[max-nextcloud]

then removing cancel-in-progress would mean an endless chain of actions being activated by a merge, no?

No. The actual build run creates a new commit and pushes it. The second run builds again, compares the output and notices there's nothing to push. That would stay the same as it currently is. It's just that the second run would not cancel the first one after it already pushed its commit anymore.

[mejo-]

Aha, thanks for the explanation, makes sense. And thanks for looking into this!

[max-nextcloud]

I wonder whether something like https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#running-your-pull_request_target-workflow-when-a-pull-request-merges would be better.

I was looking into something similar but this is even closer to it. However we also need to rebuild the js assets after the transifex changes have been pushed and they are pushed directly to master.

I wonder if we could do something like this:

on:
  pull_request_target:
    types:
      - closed
    branches:
      - main
      - stable30
      - stable29
      - stable28
  push:
    paths:
      - l10n
    branches:
      - main
      - stable30
      - stable29
      - stable28