Remove support for IngressRoute and Routes

[fibbs]

As decided in #106 I hereby remove this Helm Chart's support for IngressRoute and Route objects altogether.

We have decided that as these Ingress Controllers (Traefik and Openshift) also support standard Ingress objects nowadays, it is no longer necessary to support those CRDs in our Helm Chart.

Additionally to that, we have another, soon to be merged PR #121 which implements the possibility to render arbitrary Manifests together with this Chart.

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• DCO signed
• Chart Version bumped

[fibbs]

@aeciopires Haven't you added the creation of Helm-Docs to Github Actions automatic CI/CD? I am asking because it's still noted here as a requirement to create a pull request. If so, could you please change this documentation, accordingly? Thanks

[aeciopires]

Hi @fibbs!

Thanks for your contributition.

The publishing of the helm chart is associated with the manually created tag. Using this approach, I can accumulate many PRs and publish all the changes together. That is why I did not add helm docs to the pipeline to avoid conflicts. I had a lot of problems with this last year.

So, during the process of publishing a new release, I evaluate all the changes from the PRs that I will publish, choose the appropriate version number and then publish them in one package...

The explanation for this is that last year I was very busy at work, so several PRs accumulated throughout the year and I published them all in one batch release.

Another reason is that some people who opened the PR were not responding quickly when I had free time (which is normal because everyone's schedule is asynchronous even depending on their interest and free time).

[aeciopires]

Hi @fibbs!

What do you think about using this PR to also remove the values ​​and manifests related to Karpenter?

Looking at your PR and contribution of @sinux-l5d in #121, now it is flexible for anyone to add whatever manifest they want to the helm chart according to their needs without us having to worry about approving it for each release.

I think that the next release of chart is a break change with this values. I think that 7.0.0 version if the new release is more appropriated. Do you agree?

[fibbs]

The publishing of the helm chart is associated with the manually created tag. Using this approach, I can accumulate many PRs and publish all the changes together. That is why I did not add helm docs to the pipeline to avoid conflicts. I had a lot of problems with this last year.

So, during the process of publishing a new release, I evaluate all the changes from the PRs that I will publish, choose the appropriate version number and then publish them in one package...

The explanation for this is that last year I was very busy at work, so several PRs accumulated throughout the year and I published them all in one batch release.

I was actually thinking about exactly the same: not raising versions at PRs anymore and to do that "centrally" by one, you or maybe some day me as well :-) So, we should change the documentation of how to contribute anyway and not mention the helm-docs creation nor the version updating, right?

[aeciopires]

I agree @fibbs. Can you adjust the documentation in this PR and remove any reference related to Karpenter in values and manifests?

Other point, can you change the READ.me.gotmpl file explaning the break change related to ingressRoute, Route and Karpenter because the new feature is implemented in #121?

[fibbs]

Other point, can you change the READ.me.gotmpl file explaning the break change related to ingressRoute, Route and Karpenter because the new feature is implemented in #121?

I have documented this last breaking change with version "6.1". It depends on how you would prefer to go with the versioning from now on, but I personally believe that "major version" should be the "dot-release", when "minor" is the dot-dot release: 6.0.2 -> 6.0.3 would then be a minor upgrade, no changes in any apis, interfaces etc. should be necessary, and 6.0.2 -> 6.1.0 should be a major (where you have to check whether to modify your values.yaml). I believe this classification would fit the development of this Chart better.

[aeciopires]

Hi @fibbs!
Thank you so much for changes.
I requested undo some changes in values.yaml file related to indentation of some comments in helm-docs format.

Thanks too for explanation about the new proposal of semantic version of this helm chart. I agree with you.

The next release will be 6.1.0.

I beleave that we need wait the merge of #121 before merge this PR. This way we can resolve possible code conflicts. Do you agree?

[aeciopires]

Great job @fibbs!

I suggest to create a new section called:

Only code mainteners

To generate a new release of the helm chart do this:

• Review and merge the opened PRs;

• Run local tests;

• Create a branch. Example:

git checkout -b BRANCH_NAME

Make sure you are on the correct branch using the following command. The branch in use contains the '*' before the name.

git branch

• Make your changes and tests to the new branch.

• Verify the syntax errors using the follow commands:

cd charts/zabbix
make lint

• Analyse the changes of the PRs merged and set a new release using the follow aproach:

"major version" should be the "dot-release", when "minor" is the dot-dot release: 6.0.2 -> 6.0.3 (example) would then be a minor upgrade, no changes in any APIs, interfaces etc. Should be necessary, and 6.0.2 -> 6.1.0 (example) should be a major (where you have to check whether to modify your values.yaml).

• Change the version and appVersion parameters (helm chart and Zabbix version respectively) in charts/zabbix/Chart.yaml and charts/zabbix/artifacthub-pkg.yml files.

• Run the follow commands to update the documentation of the helm chart.

cd charts/zabbix
make gen-docs

• Commit the changes to the branch.

• Push files to repository remote with command:

git push --set-upstream origin BRANCH_NAME

• Create Pull Request (PR) to the master branch. See this tutorial

• Update the content with the suggestions of the reviewer (if necessary).

• After your pull request is merged to the master branch, update your local clone:

git checkout master
git pull upstream master

• Clean up after your pull request is merged with command:

git branch -d BRANCH_NAME

Then you can update the master branch in your forked repository.

git push origin master

And push the deletion of the feature branch to your GitHub repository with command:

git push --delete origin BRANCH_NAME

• Create a new tag using to generate a new release of the helm chart using the follow commands:

git tag -a 6.1.0 -m "New release" #example
git push upstream --tags

• The before commands will start the pipeline and will generate a new release and tag in standad zabbix-6.0.0.

• To keep your fork in sync with the original repository, use these commands:

git pull upstream master
git pull upstream master --tags


git push origin master
git push origin master --tags

• After this, edit and adjust the text generated automatically for new release and adjust the release notes follow the examples the other releases published in https://github.com/zabbix-community/helm-zabbix/releases

Reference:

• https://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/

What do you think @fibbs? Feel free to adjust the content...

[aeciopires]

Thanks @fibbs.

Very good