Closed achetronic closed 2 years ago
@achetronic thanks for highlighting this. I have been maintaing the operatorhub process manually as of now, and need to update it for 0.0.7. As of now operator release is cut manually and docker image is updated on each release.
Regardless of release process being manual, the operator code base is trusted to be used on production, and is being actively maintained and monitored.
cc @nishantmonu51 any suggestions to improve release process will be helpful.
@achetronic thanks for highlighting this. I have been maintaing the operatorhub process manually as of now, and need to update it for 0.0.7. As of now operator release is cut manually and docker image is updated on each release.
Regardless of release process being manual, the operator code base is trusted to be used on production, and is being actively maintained and monitored.
cc @nishantmonu51 any suggestions to improve release process will be helpful.
Yes, I know is quite reliable code because we use it in our company :) but one of the concerns is about, at least, to automate the release process in all the places at the same time and use the right SemVer pattern. I think this will help a bit to use it remotely and not to do a fork, as far as it is our case (and I would prefer to use it from remote, sincerely)
What do you think about this?
Hello there,
I have noticed several possible failures that affects this project in production environments, like ours. I mean, in terms of trust. They are all related to the way the releases are launched, I explain myself:
On operatorhub.io, the current is 0.0.6 but in Github the current version is 0.0.7 and this indicates that both are done by hand and not by automation with a github action or another pipeline.
What do you think about this? Is there a chance to start improving this to be trusted on production? Thank you