Onboard Renovate to repo.

[cevich]

No description provided.

[cevich]

Note: I named it json5 instead of json because the former allows comments. But I can rename to json if that's preferred.

[lmilbaum]

LGTM

[lmilbaum]

Note: I named it json5 instead of json because the former allows comments. But I can rename to json if that's preferred.

The json5 is actually preferred. The location might be a problem if the repo is synced to gitlab at some point.
Would it make sense to get the Renovate team to agree on the format and location?

[cevich]

Would it make sense to get the Renovate team to agree on the format and location?

Edit: ...deleted... I didn't read carefully enough.

[cevich]

The json5 is actually preferred. The location might be a problem if the repo is synced to gitlab at some point.
Would it make sense to get the Renovate team to agree on the format and location?

I'm assuming "Renovate team" means upstream?

Docs: https://docs.renovatebot.com/config-overview/#repository-config

If the repos are sync'd I think we specifically don't want renovate operating on them twice. We'd end up with PRs/MRs on the same topic in different systems. Unless I'm misunderstanding the question.

[lmilbaum]

The json5 is actually preferred. The location might be a problem if the repo is synced to gitlab at some point.
Would it make sense to get the Renovate team to agree on the format and location?

I'm assuming "Renovate team" means upstream?

No. I referred to our internal Renovate team

Docs: https://docs.renovatebot.com/config-overview/#repository-config

If the repos are sync'd I think we specifically don't want renovate operating on them twice. We'd end up with PRs/MRs on the same topic in different systems. Unless I'm misunderstanding the question.

That is a valid argument. Let me try with a different use case. What if the repo migrated to gitlab?

[lmilbaum]

Please rebase

[cevich]

force-push: rebased

[rhatdan]

LGTM

[cevich]

That is a valid argument. Let me try with a different use case. What if the repo migrated to gitlab?

Just to follow up on this. I think we're still okay in case of migration. It seems to me reasonable to expect some items like adding a .gitlab-ci.yml and reviewing repo settings is "normal" for a migration.

In fact I could be wrong about renovate + gitlab ignoring .github/ files. Searching there IIUC, is part of the bot's logic and it may not care what's actually hosting the repo.

[lmilbaum]

That is a valid argument. Let me try with a different use case. What if the repo migrated to gitlab?

Just to follow up on this. I think we're still okay in case of migration. It seems to me reasonable to expect some items like adding a .gitlab-ci.yml and reviewing repo settings is "normal" for a migration.

In fact I could be wrong about renovate + gitlab ignoring .github/ files. Searching there IIUC, is part of the bot's logic and it may not care what's actually hosting the repo.

I don't want to drill into it. We can always wait until such a use case is actually happen and then take action.
Just a food for thought. What is the advantage of having the renovate config file "hidden" inside the .github folder?

[cevich]

What is the advantage of having the renovate config file "hidden" inside the .github folder?

Purely organizational, as it serves no direct function in the project, i.e. I see it as a kind of meta-config. It also keeps the repo-root ("Prime real-estate") clutter-free. But I don't have very a strong opinion, if it needs to live at the root for consistency with other projects, I'm fine with that.