ci(helm): auto public Helm chart after PR merged

[afdesk]

Description

Trivy publishes a new Helm Chart only for major versions (ex 0.55.0).

This PR suggests next workflow:

• if there are any changes in helm folder ('helm/trivy/**'), the test will be run.

• if a new tag is pushed will be created a new PR with update a new version of Helm Chart.

• Helm Chart will be published, after the PR with new version is merged.
  The action runs helm test before publishing again to check that everything is still OK
  (ex. Trivy image wasn't removed).

Tests with mage command

I've tested this update in my fork:

• create a new tag: https://github.com/afdesk/trivy/actions/runs/11385428591/job/31675255326
• a new PR: ci(helm): bump Trivy version to 0.56.2 afdesk/trivy#84
• test a new PR: https://github.com/afdesk/trivy/actions/runs/11385449842/job/31675325933
• merged PR: https://github.com/afdesk/trivy/actions/runs/11385515807

Refs:

• https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#running-your-pull_request-workflow-when-a-pull-request-merges

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[DmitriyLewen]

Hello @afdesk

I left a comments.

Do you have a test action in your fork? If yes, please add a link to this run in the PR description.

Trivy publishes a new Helm Chart only for major versions (ex 0.55.0).

I didn't find conditions for that.

[afdesk]

Trivy publishes a new Helm Chart only for major versions (ex 0.55.0).

I didn't find conditions for that.

This condition works only for major version, because backport branch usually doesn't contain a Helm Chart update.

trivy/.github/workflows/publish-chart.yaml

Lines 51 to 52 in aeb7039

	publish-chart:
	if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'

[DmitriyLewen]

This condition works only for major version, because backport branch usually doesn't contain a Helm Chart update.

Oh... You said current behavior. I thought it was new logic.
then I have no questions about it

[DmitriyLewen]

a new PR: afdesk#72

IIUC author of PR should be aqua-bot (as for backport (e.g. #7521))

[afdesk]

a new PR: afdesk#72

IIUC author of PR should be aqua-bot (as for backport (e.g. #7521))

it seems it depends on token owner, because I tried to keep the same workflow:

trivy/.github/workflows/backport.yaml

Lines 48 to 58 in 5dd94eb

	- name: Set up Git user
	run: |
	git config --global user.email "actions@github.com"
	git config --global user.name "GitHub Actions"
	- name: Run backport script
	run: ./misc/backport/backport.sh ${{ env.BRANCH_NAME }} ${{ github.event.issue.number }}
	env:
	# Use ORG_REPO_TOKEN instead of GITHUB_TOKEN
	# This allows the created PR to trigger tests and other workflows
	GITHUB_TOKEN: ${{ secrets.ORG_REPO_TOKEN }}

[afdesk]

I had concerns about label (lifecycle/active) and about versions (that chart version is equal trivy version now).

@itaysk @knqyf263 wdyt? thanks

[DmitriyLewen]

it seems it depends on token owner

you said this and I realized that most likely you are right and I have already encountered this 👍

[knqyf263]

label (lifecycle/active)

Do we need a label?

about versions (that chart version is equal trivy version now).

They should be different; otherwise, we can't update the chart version when we fix the Helm chart itself.

[afdesk]

@knqyf263 @DmitriyLewen I've updated a version changing.
Could you take a look at this PR again when you have time?
thanks a lot!

[DmitriyLewen]

What do you think about using https://github.com/aquasecurity/go-version/blob/main/pkg/semver/version.go?
you can get minor and patch parts
also you can increment version part

[afdesk]

done 1e4b16c

[DmitriyLewen]

I may be wrong, but I remember that the events for merging a PR by default and merging using merge queue may be different.
Does this work correctly?