Configure renovate to update dependencies in the folder template instead of generated files.

[msclock]

I just notice that it excludes template folder updates from renovate in renovate configuration file renovate.json:

ss-python/.renovaterc.json

Lines 7 to 9 in 92e4a17

	"ignorePaths": [
	"**/template/**"
	]

The settings mean we have to do some mannual updates for template folder.🤔 See:

• chore(deps): pin dependencies #329
• chore: specify the versions of GitHub Actions #336

Why don't we accept the prs from renovate in the folder template. I consider we could focus on the template itself instead of the generated files.

[huxuan]

More specific renovate configuration are needed to update those jinja templates. So I suppose to split it into two (or three) steps:

0. Update generated files to verify the configuration need to be included in the template.
1. Update template (one of the tasks in Renovate Integration #188), this is for template only.
2. Isolate generated files into different repository (Isolate demo project from template project. #328)

Currently, it is more like renovate's default behavior. When the generated files are isolated, it will no update generated files any more.

[msclock]

More specific renovate configuration are needed to update those jinja templates. So I suppose to split it into two (or three) steps:

0. Update generated files to verify the configuration need to be included in the template.
1. Update template (one of the tasks in Use Renovate instead of dependabot #188), this is for template only.
2. Isolate generated files into different repository (Isolate demo project from template project. #328)

Currently, it is more like renovate's default behavior. When the generated files are isolated, it will no update generated files any more.

My suggestion is to add the file name convention matches of relative renovate supported managers. These settings require more tricky steps. There're some links:

• https://docs.renovatebot.com/configuration-options/#matchmanagers
• https://docs.renovatebot.com/modules/manager/#supported-managers

[huxuan]

My suggestion is to add the file name convention match relative renovate supported managers. These settings require more tricky steps. There're some links:

• https://docs.renovatebot.com/configuration-options/#matchmanagers
• https://docs.renovatebot.com/modules/manager/#supported-managers

Yes, you are right. As you may also noticed, there is no packageRules in the configuration, I will add more in the next step. Your pull request are also welcome. :-)

[huxuan]

For template, seems we have to use customManagers for everything, since github-action and gitlabci managers need to parse the yaml files, so those jinja templates will not work. An example of the error message can be found here: https://github.com/huxuan/ss-python/actions/runs/8062322285/job/22021812203

There are several options:

1. Only expose pep621 manager to end users and only update github-action and gitlabci alongside with template itself. For template, use customManagers to update those corresponding items. The downside of this option is the flexibility of github-action and gitlabci related items.
2. Use customManagers rather than github-action and gitlabci both for the template and end users. The downside of this option is the readability since users will get an unnecessary complicated configuraiton.
3. Use customManagers for template and github-action and gitlabci for end users, the downside of this option is the maintainability since we have to maintain two approaches for similar task.

Any comments?

[msclock]

For template, seems we have to use customManagers for everything, since github-action and gitlabci managers need to parse the yaml files, so those jinja templates will not work. An example of the error message can be found here: https://github.com/huxuan/ss-python/actions/runs/8062322285/job/22021812203

There are several options:

1. Only expose pep621 manager to end users and only update github-action and gitlabci alongside with template itself. For template, use customManagers to update those corresponding items. The downside of this option is the flexibility of github-action and gitlabci related items.
2. Use customManagers rather than github-action and gitlabci both for the template and end users. The downside of this option is the readability since users will get an unnecessary complicated configuraiton.
3. Use customManagers for template and github-action and gitlabci for end users, the downside of this option is the maintainability since we have to maintain two approaches for similar task.

Any comments?

I would recommend option 2. Because the scaffold instance is instantiated by the template files, and the consistancy between the generated and the template are essential. Moreover, it is not necessary for users to care about the scaffold instance configured dependencies. If users really need another dependency manager from renovate, it is all up to them.

[huxuan]

I would recommend option 2. Because the scaffold instance is instantiated by the template files, and the consistancy between the generated and the template are essential. Moreoover, it is not necessary for users to care about the scaffold instance configured dependencies. If users really need to another dependency manager from renovate, it is all up to them.

OK, in this way, I may still prefer to have #340 merged first so that I can check the extracted deps. #343 is also somehow dependency since it introduces regex manager.

[huxuan]

According to previous discussion, maybe we can close this issue?

[msclock]

According to previous discussion, maybe we can close this issue?

it's ok.