Elyytscha
commented
3 months ago sounds good, the only thing I wanted to add is that I personally think, a (git[hub])-branch based flow is not the best option right now until https://github.com/orgs/community/discussions/4618 is sorted out basically every workflow which is not trunk based (only feature branches merged into master) is doomed
only workaround is basically not using the github ui for merging or using this github action and do the merges via comments https://github.com/orgs/community/discussions/4618#discussioncomment-2795556
Is your feature request related to a problem? Please describe. Now that argocd-operator is trying to do z-stream releases for periodic Argo CD version upgrades (especially when there are important security fixes in Argo CD), we must switch to having release-based subscription channels (ie. 0.9-branch, 0.10-branch, etc). With our current setup (having only one "alpha" channel), we are unable to release any version that is not the most recent version (ex. we cannot release 0.9.2 if there is already a 0.10 release). For this reason, in order to incorporate z-stream releases, we must switch to release-based subscription channels.
In addition to this, we should also update current documentation for how to install specific operator versions and how to do manual subscription upgrades.
Describe alternatives you've considered We have tried only using one channel when attempting the argocd-operator v0.9.2 release, but when updating the replaces statement in the CSV of v0.10.0 from
replaces: 0.9.1toreplaces: 0.9.2, we ran into an issue in the community-operators-prod repo where checks fail due to modifying an existing operator, which is not allowed (note: it is however allowed in community-operators repo)Additional context Check that fails in community-operators-prod: