[CM T0] add dependabot.yml file

[markus2330]

https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#labels

should be configured to:

• [x] use our labels (lang/javascript and lang/java instead of javascript and java)
• [ ] exclude files which are not security relevant
• [ ] don't run too often

[markus2330]

@mpranj do you have other suggestions how it should be configured?

[mpranj]

I think it would be great to exclude code (e.g. webui), which have no maintainer and are likely unused (currently).

I think the exclusion comes implicitly as you have to list all package manifests explicitly in the dependabot.yml file (according to docs).

[kodebach]

All the PRs created by dependabot fail because of the missing line in the release notes. I don't think there is a direct way to tell dependabot to add such a line. AFAICT our options are:

1. Manually fix every dependabot PR (kinda defeats the purpose)
2. Modify the Jenkins CI, so that PRs by dependabot don't need a release notes line
3. Maybe a Github Action could be used to automatically add the release notes line to PRs created by dependabot (see also https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions).

[lukashartl]

I think we should opt for option 2. As we use Jenkins for most parts now, we should stick with it. The script scripts/build/run_check_release_notes checks whether a new line has been added to the release notes. Dependabot uses branch names that start with dependabot/, so we could just skip the check if the branch name starts with dependabot/.

/cc @markus2330 what do you think?

[kodebach]

The disadvantage of this would be that automated dependency updates are not mentioned in the release notes unless we manually add them later.

IMO using GitHub Actions in this case would be fine, because dependabot is specific to GitHub anyway. If we switch to different git hosting, none of this will work, not just the Action for the release notes.

[markus2330]

I don't think that we have to do any automation in this case: dependabot didn't do anything for quite a long time, only recently a few PRs showed up (and probably even less would show up once we do the exclusion of non-security relevant files). So continue doing everything manually is a sensible choice. The patches from dependabot are trivial, writing the release notes is the main effort of the whole affair. And automating this doesn't make much sense: a human must decide how important it is to highlight it (or even to do a release earlier so that people get an update). Nothing is wrong to see the PRs as pure information without ever merging them.

[kodebach]

I'm not sure why dependabot didn't create PRs. Maybe because we didn't have a config file. However, some of the dependencies that are updated in the recent PRs are years out of date. So the PRs did not just show up, because the dependencies had recent updates. In fact in the JavaScript world some libraries are updated multiple times a week, or even multiple times in a single day.

If we have to manually merge all of those PRs that could be a lot of work. So at least the exception in the release notes check is needed IMO. Also dependabot has a limit on the number of concurrent PRs it opens and only updates a single dependency per PR (AFAIK). So it could very well be that the moment we merge the current PRs, new ones are opened.

We should probably update everything manually right now, because having 100s of separate PRs is just gonna take forever to filter through the CI and will block other, more important things, because of concurrency limits.

[markus2330]

We need to be somehow realistic for our release cycle. It would be absolutely pointless to update the versions multiple times a week.

[kodebach]

The point of dependabot is that you don't need to think about your dependencies. It just creates the PR, lets the CI run and then you merge it (or you even have an auto-merge) or close the PR to ignore the new version.

That said, you can define in the config file how often dependabot checks for new versions (currently daily).

Also I'm not sure how our release cycle plays into this. We don't need to release a new version every time some dependency got updated. The point of dependabot is just that when we do decided to release a new version, all our dependencies will already be up-to-date.

[kodebach]

Here's an example of what happens, when dependencies are updated frequently: https://github.com/ElektraInitiative/libelektra/pull/4379#issuecomment-1162449461

dependabot sensibly closes the old PR and opens a new one. But if PRs need manual intervention or we just don't merge them and just leave them lying around, dependabot just creates unnecessary load on the CI servers.

[markus2330]

Please do not get entangled too much in unimportant issues. It is unimportant because:

We don't need to release a new version every time some dependency got updated.

Releases is what people are supposed to use. Every update in between is just for us developers.

dependabot just creates unnecessary load on the CI servers.

It does not so much because we abort early if no release notes are found.

[kodebach]

I don't understand why this unimportant...

What I understood is: You suggest that we should publish a new version of Elektra every time a dependency gets updated. That seems crazy to me. First of all to make this at all feasible we would need a continuous deployment setup that fully automatically creates all the release artefacts so that just need to press a button to give it a number an publish it. But even then that is a weird idea to me. IMO when a library has a new release this means something interesting has happened. Maybe a bug got fixed, maybe a new feature got added, maybe it is now faster, etc. But if some obscure Javascript library only fixed some bug in a part of the library we don't even use, publishing a new release for Elektra would be very weird.

It does not so much because we abort early if no release notes are found.

This only applied to Jenkins. Which IMO is the least important in that case, since we have full control there. If we run out of resources we could probably deprioritise PRs created by dependabot (or something similar). More important IMO is that the dependabot PRs will clog up the Github Actions and Cirrus CI resources. If the PR would then be fully checked and mergeable (or auto-merged) this would be fine, but the way it is now it is just waste. And even on Jenkins we use some resources for PRs that we know will never run successfully.

[github-actions[bot]]

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:

[github-actions[bot]]

I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart: