(Enhance) dependency update process

Hey guys, not sure if a meta discussion is right here, but I couldn't find a better matching sub forum either. Sorry for the long text, I hope to understand things a little better and probably I'm then able to effectively help bots finishing their job during calm night hours or so 😄.

To fix CI/CD tests for a PR of mine, I reviewed them a bit, compared results with other PRs to verify whether a failure is caused by my changes or not, and indeed some checks were solved by a rebase onto current master.

I then noticed that a lot of dependabot PRs hang as well on such "formal" check failures, while the bot reports 100% compatibility, nextcloud-bot requested a merge (what is actually the trigger for that?) and approved it together with github-actions bot, so that it could have been merged automatically without human interaction, if the CI/CD tests were gone through. I played a bit with the bots PRs and indeed in some cases a simply rebase request solved it and hence triggered an automated merge, so far so good.

Now there are some other possible issues which may delay or break those automated dependency bumps, also for security-related ones, being open for months. Aside of the fact that the related security patch is then missing, it also accumulated a long list of open PRs, making it difficult to keep human-made PRs in view, which are moved back page by page.

One commonly failing check is the one for JavaScript build changes. From what I understand, this is as the repository does not only contain source code, but compiled JavaScript as well. So when a Node module is bumped, which has an effect on any of these scripts, a re-build within the test leads to changed files and then we get something like this:

Run bash -c "[[ ! \"`git status --porcelain `\" ]] || ( echo 'Uncommited changes in webpack build' && git status && exit 1 )"
Uncommited changes in webpack build
HEAD detached at pull/26730/merge
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   apps/files/js/dist/personal-settings.js
	modified:   apps/files/js/dist/personal-settings.js.map
	modified:   apps/user_status/js/user-status-menu.js
	modified:   apps/user_status/js/user-status-menu.js.map
	modified:   apps/weather_status/js/weather-status.js
	modified:   apps/weather_status/js/weather-status.js.map
	modified:   apps/workflowengine/js/workflowengine.js
	modified:   apps/workflowengine/js/workflowengine.js.map
	modified:   core/js/dist/login.js
	modified:   core/js/dist/login.js.map
	modified:   core/js/dist/main.js
	modified:   core/js/dist/main.js.map
	modified:   core/js/dist/unified-search.js
	modified:   core/js/dist/unified-search.js.map

To solve this, as far as I understand, /compile amend / can be done to trigger a rebuild and amend by npmbuildbot-nextcloud. The issue then is that dependabot denies to further handle the PR, as it has been modified by someone/something else. So a manual merge is required then.

• I'm not sure how these bots can be configured, but wouldn't it be possible to have a JavaScript module bump directly combined with a rebuild, and/or allowing dependabot to auto-merge requests which were modified by npmbuildbot-nextcloud, as long as all tests went through, of course?
• Else what is the best approach to handle such cases?
  EDIT: In the meantime, dependabot is able to auto-merge PRs after the compile bot did its job, given all checks passed and two approvals.
• EDIT: Another suggestion is to have the compile bot remove obsolete files as well: https://github.com/skjnldsv/npmbuildbot/issues/174

And then there is dependabot-preview, which is still opening PRs (at least it did 1.5 days ago), but is now not able to further deal with them anymore, so all it's PRs need to be in case rebased or merged manually. Open PRs by it block dependabot (non-preview) from opening own ones, as the branch it would create does already exist. As the PR is only handled by the bot (version) that opened it, I guess dependabot-preview should be disabled, and all it's PRs either closed (to have them re-opened by dependabot) or manually reviewed and merged. This is where most security dependency bumps are hold a long time, like #26730. EDIT: Disabled in the meantime.

Then another minor issue with the drone Selenium acceptance tests:

Starting ChromeDriver 90.0.4430.24 (4c6d850f087da467d926e8eddb76550aed655991-refs/branch-heads/4430@{#429}) on port 21084
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully.
[1623151991.858][SEVERE]: bind() failed: Cannot assign requested address (99)

All logs are spammed with these errors, while it seems to not affect the test results. I just recognised as I had a look into the long taking ones, and thought that this might be the reason.
EDIT: In the meantime I think I understand the tests better and Selenium is just running as a provider for the actual tests and prints the above warning on every actual test scenario, right?

And generally: While the GitHub tests are for free (?), the drone has some limit, doesn't it? I mean not only for concurrent tests but also overall tests in a certain time range, so that commits/pushes shouldn't be spammed (anyway)? I see the drone sometimes Waiting for status to be reported, but sometimes it starts regardless 🤔.

Start by reviewing the dependency PR checks and the compile-bot workflow referenced in the issue, including the listed apps/*/js/dist and core/js/dist outputs and the /compile amend / command. Done would need a defined, tested process for dependency bumps to rebuild generated JavaScript and complete automatically, but the issue does not identify a current entry point or acceptance criteria, and several concerns are marked resolved.