enhancement: introduce release channel capability

[fschade]

Description

set the edition capability to a build time flag which represents the release channel! Available channels are:

• dev: local builds and builds without ldflags $(OC_REPO)/pkg/version.Edition=$(EDITION)
• rolling
• stable
• lts-0.0.0, the contained version number must follow semver!

unfortunately oc had the public config sets for setting the edition as part of the config or as env variable such as:

• config:edition
• env:OC_EDITION
• env:FRONTEND_EDITION
• env:OCDAV_EDITION

the ability to configure that value has been removed as part of the pr, deprecating the env is not easy and it should not be in use anyway, but who knows..., @micbar lets discuss, i still can change the behavior!

Related Issue

• Fixes create a buildflag for stable / rolling version #1580
• Enables Announce if running a stable or rolling version #1549

Motivation and Context

Having detailed information of which build channel the current server binary is originated from, web also requested such a capability to display it.

Todos:

• add the Env:EDITION to the each related block of our woodpecker.yml
• add the Arg:EDITION to all related docker images
• check web, just in case
• get green light from @TheOneRing

Questions:

• Q: Should our make step automatically parse the current branch to determine the current Env:CHANNEL, should work out of the box for stable, but what about rolling and nightly?

  • A: ✅
    • ci binary builds are always of type edition:rolling
    • ci docker production builds are always of type edition:stable
    • ci docker other builds (rolling, and daily) are always of type edition:rolling

• Q: if the channel is unknown running the binary fails (i added a validation for that), current allowed values are: rolling, rolling, stable, and lts-0.0.0, in other words, it panics with a message, ok or maybe we should just log a warning!? ..., @kulmann, @micbar

  • A: ✅ @flimmy and myself decided not to panic, it logs an error instead and falls back to its edition default value which is dev

• Q: any woodpecker magic needed? Tags, manuall triggered ci runs, ..., @flimmy

  • A: ✅ nope, default type is daily which results in an rolling edition

• Q: removing env:OC_EDITION, ... without deprecating it is ok!?

  • A: - ✅ undocumented

How Has This Been Tested?

• manually checking the capability (edition)

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation added

[fschade]

@kulmann, @db-ot FYI

[flimmy]

looking good