Trim renovate config

[senekor]

• Remove custom config for warpy

  We don't use warpy anymore.

• Don't update the lockfile

  The site is generated with Zola. All our regular Rust dependencies are
  essentially dev dependencies, used for testing and the blog post
  generator. Updating the lockfile weekly only causes frequent
  recompilation for no significant benefit.

• Unpin dependencies

  The site is generated with Zola. All our regular Rust dependencies
  are essentially dev dependencies, used for testing and the blog post
  generator. Pinning them to the patch release only causes frequent
  recompilation for no significant benefit.

[senekor]

@Turbo87 you introduced the renovate config, what do you think about these changes? Are you ok with relaxing the config a bit?

[Turbo87]

We don't use warpy anymore.

very happy to hear that 😅

Don't update the lockfile & Unpin dependencies

I'm not so sure about these changes. Specifically for applications I tend to pin everything down as much as possible to avoid upstream changes randomly breaking the build and then I rely on bots to open PRs to explicitly update the versions. I don't know how Zola is currently used but I'd even pin that version down to the patch release if possible. I've rarely had some version update randomly break my builds or CI since I started doing that.

There is some more information on that topic over at https://docs.renovatebot.com/dependency-pinning/. It is targeted mostly at the JavaScript ecosystem, but the same basic principles apply to Rust too.

Are you ok with relaxing the config a bit?

Since you're the primary maintainer of this project this is totally up to you. I won't veto the decision if you want to go that way :)

[senekor]

Specifically for applications I tend to pin everything down as much as possible to avoid upstream changes randomly breaking the build

My first thought was: "Isn't that what the lockfile is for?" And sure enough, this section of the documentation you linked talks about it. IIUC it boils down to this: Updating a whole bunch of dependencies at once via a lockfile makes it harder to find out which specific library is responsible when something does go wrong.

But my point is that we can be 100% certain that such a dependency update won't break our build, because the remaining Rust code doesn't actually build the site. It's just some tests that make sure front matter is in order and a little utility for generating boilerplate of a new blog post.

I think it's just disruptive for no benefit to have contributors recompile this stuff for every patch release.

I don't know how Zola is currently used but I'd even pin that version down to the patch release if possible.

Yes, Zola is pinned to a specific commit with a submodule. I don't think that should be relaxed, because Zola is what's actually building the site.

[Turbo87]

I think it's just disruptive for no benefit to have contributors recompile this stuff for every patch release.

yeah, I think that's reasonable. I'd personally still keep it pinned though and instead reduce the frequency of the update PRs, but that's up to you :)

Yes, Zola is pinned to a specific commit with a submodule. I don't think that should be relaxed, because Zola is what's actually building the site.

yep, that makes sense 👍

[Manishearth]

Convinced by the arguments that we don't need to pin this.