T-Systems-MMS/phonebook

renovate-bot "automergetype" evaluation

Opened this issue · 12 comments

I think that we talk about to use https://docs.renovatebot.com/configuration-options/#automergetype in the future for patches and maybe minors.

It's very annoying that renovate opens a new PR for every patch.

Let me know what you think about @T-Systems-MMS/phonebook-developers

Well thats how versioning works :P
In my private repos I have automerge enabled for minors and patches

Okay and it looks like its still not possible to automerge with renovate if an organization is the owner of the repository..

Do you have any other idea how we can automerge the dependencies @DanielHabenicht, @paule96 ?
I am not sure if we can add @renovate-bot to the @T-Systems-MMS/phonebook-developers group, but if it's possible automerge should also working.

ping @T-Systems-MMS/phonebook-developers

The pull requests will be more and more...

First off, there will be even more in the future 😆
The only way is to update:

  1. Merge the blocking fix for the preview.
  2. Merge PR from renovate bot to get a feeling for packages that might error in master (read the release notes of the update, have a look at what the package does)
    • if there are chore commits you can merge them without having to fear that it will introduce a bug in prod (all that can go wrong is a failing build)
    • if they are fix commits I kindly suggest to make a preview build and have a look that nothing did break because they can impact prod without turning on a warning light

If there is a general consensus about "save" package updates we can add them to the renovate config so they get auto-updated (maybe even for major bumps)
At the moment we can't auto-update anything because we do not have enough test coverage to be sure that the application will fail on update if something is broken.
Being up to date is a tedious job Maybe we can also configure renovate to open PRs every 7 days but the count of PR will stay the same.

The big problem for me is that we need two reviewers for the dependencies. It would be cool if all branches with renovate/* want to merge into master don't need any review or just one review by @T-Systems-MMS/phonebook-admins or a review by the codeowner or something like.

I am also not sure if we are ready to need two reviewers for merge. I am with you that this will result in better code quality and minimize the risk of wrong merged code, but if code is merged wrongly we can revert and don't need to deploy on live systems. The problem is that we are not that many people, have sometimes not that much time and new developers won't wait days or weeks for our reviews and maybe loose there desire.
Let us talk about this next month with the team :)

@DanielHabenicht
@paule96 and me decide to make merging for all @T-Systems-MMS/phonebook-admins possible without a review. This should only use for the dependencies. What do you think about? For us, it was the best and fastest solution :)

We want to find a solution where this behaviour is only for renovate/* into master

Yeah we might want to talk about azure-devops in this regard, seems to be a better fit.
I don't really like the idea, but go ahead.

Thanks for merging! You might have to revert the puppeteer update to v2 as this might be the issue for the failing unit tests. @mschwrdtnr

Seems like it's not. Can somebody please test locally if there are failing for them as well? (after a fresh npm install). Then try to downgrade the packages till it is working again.

Probably can do this the next days.

Can you also explain me the problem of the other failing checks?

The Chrome Webdriver and the installed Chrome version do not match. That's why there is no connection.
The solution is probably to install the matching version of chromedriver before running the test. But for E2E that's not really important as we don't really have any tests running there. But Unit tests are pretty important, so fix them first.