Helm dependencies should optionally bump chart.yaml

[adusumillipraveen]

What would you like Renovate to be able to do?
It is great that renovate supports helm dependency management now. But, it would be great if renovate can optionally bump the chart version in chart.yaml in the PR as the new chart needs to be published as a new vesion.

Describe the solution you'd like
Renovate should (optionally ) bump the chart version in Chart.yaml when raising a PR to bump requirements.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Currently one way is to manually edit it so that we can publish a new version of chart.

Additional context
NA

[JamieMagee]

Yeah, this should be possible. We already have this functionality for bumping the version in package.json using the bumpVersion option, so extending this to work with helm shouldn't be too difficult.

[travisgroth]

Hi @rarkins I'd love to see this feature included. Can I help with the requirements or testing at all?

Functionality like https://docs.renovatebot.com/configuration-options/#bumpversion would be great.

To implement this, the version field in Chart.yaml needs the increment.

[rarkins]

@travisgroth which of our managers would this be applicable to? e.g. helmv3?

It will be a little bit tricky because npm's updating approach is quite unique compared to other managers and so therefore you can't simply copy over the way it does bumpVersion too.

I think we'd need to add an optional new function to managers with same or similar signature as this one in npm:

renovate/lib/manager/npm/update.ts

Lines 7 to 58 in de5de8e

	export function bumpPackageVersion(
	content: string,
	currentValue: string,
	bumpVersion: ReleaseType | string
	): string {
	if (!bumpVersion) {
	return content;
	}
	logger.debug(
	{ bumpVersion, currentValue },
	'Checking if we should bump package.json version'
	);
	let newPjVersion: string;
	try {
	if (bumpVersion.startsWith('mirror:')) {
	const mirrorPackage = bumpVersion.replace('mirror:', '');
	const parsedContent = JSON.parse(content);
	newPjVersion =
	(parsedContent.dependencies || {})[mirrorPackage] ||
	(parsedContent.devDependencies || {})[mirrorPackage] ||
	(parsedContent.optionalDependencies || {})[mirrorPackage] ||
	(parsedContent.peerDependencies || {})[mirrorPackage];
	if (!newPjVersion) {
	logger.warn('bumpVersion mirror package not found: ' + mirrorPackage);
	return content;
	}
	} else {
	newPjVersion = inc(currentValue, bumpVersion as ReleaseType);
	}
	logger.debug({ newPjVersion });
	const bumpedContent = content.replace(
	/("version":\s*")[^"]*/,
	`$1${newPjVersion}`
	);
	if (bumpedContent === content) {
	logger.debug('Version was already bumped');
	} else {
	logger.debug('Bumped package.json version');
	}
	return bumpedContent;
	} catch (err) {
	logger.warn(
	{
	content,
	currentValue,
	bumpVersion,
	},
	'Failed to bumpVersion'
	);
	return content;
	}
	}

Then we'd need to work out where/how to call it, potentially here:

renovate/lib/workers/branch/get-updated.ts

Line 86 in 4665dbf

if (!newContent) {

[travisgroth]

@travisgroth which of our managers would this be applicable to? e.g. helmv3?

My immediate use case is for helm-values, but I believe you'd want the option on any changes to a chart. So:

• helmv3
• helm-requirements
• helm-values

[mikebryant]

I've got an implementation of this going for helmv3 at #7670 :)

[github-actions]

Hi there,

The Renovate team needs your help! To fix the problem, we first need to know exactly what's causing the bug. A minimal reproduction help us to pinpoint the exact cause of the bug.

To get started, please read our guide on minimal reproductions to understand what is needed.

We may close the issue if you have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

[multani]

I think this has been implemented in #7670 already, no?

[travisgroth]

@multani not completely. The chart version isn't bumped by the helm-values manager AFACT. The practical result is that if you bump your image version, the chart metadata isn't updated. Only updates to your chart's dependencies properly bump the chart version.

You can see the difference in these two PRs:

https://github.com/pomerium/pomerium-helm/pull/232/files (helmv3 manager update)
https://github.com/pomerium/pomerium-helm/pull/239/files (I believe this is a helm-values update)

[travisgroth]

@rarkins @HonkingGoose any chance of this getting some attention?

[rarkins]

@travisgroth the issue labeled with help wanted and reproduction:needed, so unfortunately not. Once there's a minimal reproduction and we think the requirements are clear then we'll update to status:ready, after which a community contribution would be needed

[roobre]

Hi @rarkins,

I am interested in seeing this feature happen for the helm-values manager, and me or maybe one of my teammates should be able to contribute with a PR, hopefully covering the "community contribution would be needed" part of your comment.

Is there any way we can help with the "Once there's a minimal reproduction" part? Should a PR made by helm right now be sufficient, or were you thinking about something else?

Thanks!

[rarkins]

Hi @roobre, a PR would be most welcome. You're also welcome to jump straight to the PR if you're confident in it. Normally we recommend for contributor's sakes to create a reproduction and discuss how it would work within the issue first, just to reduce the chance of misunderstandings.

[roobre]

Hey @rarkins,
I totally get it, we do the same for our OSS projects 😄

In this case we might jump straight to the PR as you suggest because I think the base functionality is pretty much what the title of this issue says. Of course we can discuss any detail in the PR :)

I'll add this to the team's backlog and see if we can get to work on it soon!

[viceice]

is helm values manager for the EOL helm version V2?

[roobre]

@viceice As far as I can tell helm-values is still useful for helm 3. helm-requirements is the one that is probably not useful with Helm version 3 and onwards, as it targets a file called requirements.yaml which is no longer recommended with the new format for Chart.yaml that Helm versiom 3 introduced.

[secustor]

No, helm-values is used for both. V2 & V3

helm-requirements is only valid for V2

[jessebot]

is there additional testing required to move this forward after @roobre's comment, #4728 (comment) ?

[rarkins]

This issue has label status:ready which means PRs are welcome

[kvanzuijlen]

@rarkins I'd be willing to take a crack at this, as it would also help out big time for what I'm working on with jenkinsci/helm-charts#975. I hope/think I can come up with something before the end of the year. I'll keep you posted!

[kastl-ars]

OK, what is the state on this one? It was closed and reopened in January?

Apparently reverted in #26758

[github-actions]

Hi there,

Get your discussion fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the minimal reproduction in your own repository.
5. Fill out the information in your repository's README.md.
6. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.

Good luck,

The Renovate team

[rarkins]

Hi, could someone who's interested in this feature create a reproduction which follows our above guidelines? e.g. including a readme explaining observed vs expected behavior.

I think the best way to do this would be to:

• Create the minimal reproduction repo
• Install the renovate bot into it, to create a PR
• Add a commit on top showing the "bump" version which would be expected (this should also cause Renovate to stop updating the PR, keeping it reproduced for eternity)

[LeoColomb]

@rarkins I've just made a minimal reproduction repo: https://github.com/LeoColomb/renovate-helm-values
As requested, some README to guide and an additional commit to highlight the missing bump on the PR (LeoColomb/renovate-helm-values#1)