allow bumping puppet-agent-* deps #9410
Conversation
| @@ -191,6 +192,7 @@ def main() -> None: | |||
| specs = chain( | |||
| find_packaged_specs(), | |||
| find_gemfile_lock_specs('foreman-develop-source-release', 'foreman'), | |||
| find_gemfile_lock_specs('foreman-installer-develop-source-release', 'foreman'), | |||
There was a problem hiding this comment.
The problem is that we have many gems that are actually irrelevant for packaging. Then some things end up pulling in older gems, for example because of the old rubocop version we have (which we should update).
You can also see that we don't even pin puppet-strings in our Gemfile (https://github.com/theforeman/foreman-installer/blob/c6422b45f1bb6e1af8e9792857411b077fe306ac/Gemfile#L12) so if that's the only thing then I wonder if there's a better way.
What we can also consider is a more advanced solution where we can inherit things.
Breaking it down we have:
- Pure runtime: needed to run the installer.
- puppet-agent (can be AIO)
- Kafo (+ deps)
- Build time:
- puppet-strings (to build the parser cache)
- librarian-puppet (to download the bundled modules)
- Development / testing (irrelevant, so not specified)
Build time is actually split into two. librarian-puppet is needed to build the source tarball while puppet-strings is needed to build the cache. The reason is that it only caches items for classes included in the answer file(s). Technically we could generate one huge cache file for all the classes, but that makes the cache bigger and will slow down runtime.
So that makes me think about building some common file + Gemfile with just the ones we use in packaging (kafo, puppet-strings) and generate a lockfile for that. Then also include the common bits in the generic Gemfile.
Any thoughts on that?
There was a problem hiding this comment.
Right now, the script finds:
packages/foreman/puppet-agent-oauth 1.1.0
packages/foreman/puppet-agent-yard 0.9.34
packages/foreman/puppet-agent-puppet-strings 4.0.0
packages/foreman/puppet-agent-rgen 0.9.1
The alternative would be to add something like template: puppet to the specs and allow the script to always bump that to "latest", but I am not sure I like that.
I think having a Gemfile.lock with --without test:development would be the right thing (and would also apply to the other projects, actually, it's just that there its less of an issue).
There was a problem hiding this comment.
I'm not sure --without really ignores those dependencies. For example, if you have a git repo listed in your development group bundler will still clone it to determine the dependencies. Even if you specified --without development. That's why I suggested separate files. But there may be different ways (like looking at ENV vars).
There was a problem hiding this comment.
Yeah, I shouldn't have said --without but "a lockfile built in a way that it would not list the unwanted deps" (= what you suggested, without implying an implementation)
No description provided.