search

serious-scaffold / ss-python

An evolving Python project template that covers the full development lifecycle.
https://serious-scaffold.github.io/ss-python/
MIT License
74 stars 7 forks source link

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

Closed msclock closed 6 months ago

msclock commented 6 months ago

I just notice that it excludes template folder updates from renovate in renovate configuration file renovate.json: https://github.com/serious-scaffold/ss-python/blob/92e4a172a0968e026136a81bdc40bcf70de747f0/.renovaterc.json#L7-L9

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

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 commented 6 months ago

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

  1. Update generated files to verify the configuration need to be included in the template.
  2. Update template (one of the tasks in https://github.com/serious-scaffold/ss-python/issues/188), this is for template only.
  3. Isolate generated files into different repository (https://github.com/serious-scaffold/ss-python/issues/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 commented 6 months ago

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

  1. Update generated files to verify the configuration need to be included in the template.
  2. Update template (one of the tasks in Use Renovate instead of dependabot #188), this is for template only.
  3. 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:

huxuan commented 6 months ago

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

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

msclock commented 6 months ago

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

it's ok.