Publish `main` helm charts version on every merge

[jcchavezs]

Currently on every merge we build a main image and publish into the registry. However that can't be deployed with helm charts as those are only produced on releases. Since we provide images on every merge it makes sense we also push a helm chart for that main.

This will allow users to deploy newest changes and provide early feedback and also will slow down the hurry to do a new release on merges.

Ping @JBAhire @kotharironak @ravisingal @adriancole

[jcchavezs]

As @kotharironak pointed out helm requires semver2 (see https://helm.sh/docs/topics/charts/#charts-and-versioning). According to semver, we can still suffix versions to make it semver compliant but also to express the fact that it is not a maintained release:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.

see https://semver.org/spec/v2.0.0.html#spec-item-9

Hence we can go with 0.3.1-alpha.<commit_id>, 0.3.1-alpha.<commit_id_first_8> (to shorten the commit hash) or 0.3.1-main.<commit_id> (less exact)

[codefromthecrypt]

seems silly.. where's the actual enforcement of this policy?

[codefromthecrypt]

Intentionally following this silly policy for non-releases would put us at a disadvantage vs other products who often have more staff. For example, at least elastic do a "master" tag as their main branch is still called "master"