Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dependabot: check for github actions and bundler #3250

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bastelfreak
Copy link
Contributor

No description provided.

@bastelfreak bastelfreak requested a review from a team as a code owner November 27, 2023 12:45
@donoghuc
Copy link
Member

Given we handle packaging of gems the system packages we build, i dont want automation to be bumping dependencies at the component level.

@bastelfreak
Copy link
Contributor Author

Dependabot wont bump it automatically, if thats your concern. It will inform you about updates.

@donoghuc
Copy link
Member

For this particular repository we are trying to manage two streams (PE LTS and STS) with a single bolt version. The LTS is ruby 2.7 based and the STS is ruby 3. Straddling the line of gem compatibility is more complex than just asking for latest. I just dont see any value in running these actions for this project at this time as we have to manually update gem dependencies in our puppetlabs/puppet-runtime repository for the system packages that ship bolt.

@bastelfreak
Copy link
Contributor Author

Straddling the line of gem compatibility is more complex than just asking for latest

And because of that it's not asking for latest. It honors your ruby version requirement:

spec.required_ruby_version = ">= 2.5"

we have to manually update gem dependencies in our puppetlabs/puppet-runtime repository

So you duplicate the information from the gemspec and manage them by hand in another place? That workflow seems wrong. Is puppetlabs/puppet-runtime now the authoritative source for dependency versions? Aren't we allowed to update any dependencies in the bolt project?

@donoghuc
Copy link
Member

I think i'm confused about what these actions actually do... puppet-runtime is the definitive source about what gems actually get shipped in bolt packages. These obviously must satisfy the requirements in bolts' gemspec. So both are important "definitive sources of truth". What do these actions actually do?

@mcdonaldseanp
Copy link
Contributor

So I think this automation actually might be fine, it just might potentially be confusing for folks as to what it's doing. The gem specification here in the Bolt repo should generally be considered as the worst-case of all Bolt's dependencies in order for Bolt to work. Put another way: what's here in the gemspec specifies what's absolutely necessary to be installed for Bolt to be functional at all, not what should be installed in order for Bolt to run safely and well.

The puppet-runtime project defines what we actually ship inside public bolt packages, and therefore is the source of truth on what we consider to be the correct set of gem dependency versions to be using with bolt.

So you duplicate the information from the gemspec and manage them by hand in another place? That workflow seems wrong. Is puppetlabs/puppet-runtime now the authoritative source for dependency versions?

The information here in bolt's gemspec defines the absolute minimum bolt needs in order to run, and the puppet-runtime project defines the gem dependency versions we ship inside public packages. The two sets of information aren't actually duplicated, we're just only using gem/bundler functionality for defining minimum requirements here, and not using the functionality of those tools for pulling packages to resolve those minimum requirements.

We do that for a very specific reason, which is that bolt, and more importantly puppet, run on so many different platforms. puppet especially runs on what feels like everything under the sun. Updating gem dependencies has a long tail of testing on every platform we need the gems to work on. Additionally, like Cas mentioned, we also have multiple active supported releases of PE for which we need bolt to work with. All of which makes for an absolutely massive matrix of things to test.

So now we have puppet-runtime to determine the versions we're actually running with, and we have complete control over which gems get updated and when. That makes our lives easier because gem updates aren't constantly introducing new failures to our massive test matrices all the time because they failed to work on something like AIX or Solaris. While this certainly isn't efficient at all, it's been the best experience we've had managing deps.

Getting back to my original point: I actually think this automation is fine, it's just going to open PRs for updating the bare minimum requirements which I'm okay with. Mostly I am concerned that people will treat the information on these bare minimum requirements differently than we do: generally you probably shouldn't rely on the versions outlined in the gemspec to determine which versions you're actually using with bolt, because what's provided here is just a baseline. The actual versions you should use are the versions we ship in our public packages, which are defined in puppet-runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants