Replies: 1 comment
-
|
Nice, thanks for sharing! I could see this being an installable package, yes. This could be packaged as a Jinja extension, to be loaded thanks to copier-template-extensions. _jinja_extensions:
- copier_template_extensions.TemplateExtensionLoader
- copier_resolve_conflicts.ResolveConflictsThe Jinja extension would just add a variable to the context, so that users can use it in _migrations:
- command: >
{{ resolve_conflicts }} --regex '^\s+uses: [\w_-]+/[\w_-]+@[a-zA-Z0-9]{40} # v(?P<version>.+)$'...where This executable would be a Python script or runnable module, which would accept args like a regex to match lines and find a PEP 440 version within them, used to compare lines in conflicts and keep only the ones with latest versions. Or maybe there's an even simpler approach! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We are using copier quite a bit at my company and it works really well, thanks a lot!
One thing we often stumbled upon was that we have trivial merge conflicts like this
or
This is because next to a copier updater, we also have dependabot running for github workflow files that are not tracked by copier.
These merge conflicts are quite annoying to deal with on a large scale as it's stupid work that needs to be repeated over and over.
For this, we have written a custom
aftermigration that handles these things.This basically trivially resolves github actions merge conflicts by choosing the newest one, only if it's of the form
uses: ...@<sha> # <version>.I think this might be useful for other users as well. @sisp what do you think would be a good place for this? We could also refine this or make a custom python package out of this that people could install.
Beta Was this translation helpful? Give feedback.
All reactions