Consider changing release strategy
onedr0p opened this issue · comments
Team, I love using reloader but since I am using renovate to update it in my clusters the churn of releases are getting overwhelming. Any chance this can be addressed to not release on every merged PR to the main branch? Does every merged PR warrant a new release? Thanks.
EDIT: I understand the current way lessens the burden of having to manually craft new releases and makes it so this project is pretty much auto-piloted however not every merged PR justifies a release IMO.
Would like to highlight this part from your comment:
since I am using renovate to update it in my clusters
I could understand maybe doing this in development environment, but do you update your production clusters the same way, too? This seems very specific to your use case...
It doesn't matter, whether dev, stage or production or whatever. Changing the release strategy to being manually curated would stop things like this from being released.
This is the second time the release has been broken in the past couple months
Would like to highlight this part from your comment:
since I am using renovate to update it in my clustersI could understand maybe doing this in development environment, but do you update your production clusters the same way, too? This seems very specific to your use case...
@IdanAdar This is how many organizations update, and it just broke a few of my production work clusters.
Puts in question your production environment IMO...
Puts in question your production environment IMO...
Cause I use renovate? How are you an SRE Team Lead... olol
Because you update directly to production lolol. 🤷♂️
Because you update directly to production lolol. 🤷♂️
I never updated dev, stage or production, the PR comes from renovate for my GitOps repo, runs tests, and I can see that it fails so I don't merge it.
Your production broke because you pushed directly to it before testing it and you're complaining on someone else's release process instead of your own release process? Please...
We also get notifications in slack at work when reloader is updated. Because it's a manual process for us to update charts (because production), it becomes a chore to manually comb through a bunch of release notes to only find out the README was updated, and functionally nothing has changed.
It would be nice to only have releases when the code is changed.
Because you update directly to production lolol. 🤷♂️
You really don't understand my environment, but tried to directly criticize how I update. What's a fact here, is this merging pipeline needs to change.
Your production broke because you pushed directly to it before testing it and you're complaining on someone else's release process instead of your own release process? Please...
I have CI tests that check if image is even present, so it fails to merge. Fix this garbage release on merge pipeline.
Your production broke because you pushed directly to it before testing it and you're complaining on someone else's release process instead of your own release process? Please...
The fact of the matter this project should not be releasing builds like this in an automated fashion because there obviously isn't enough testing going on to prevent broken builds from being released, they should be manually curated like most of the other software on the internet.
"and it just broke a few of my production work clusters."
I'm not saying Reloader's release process shouldn't change, just saying yours could too. You don't have to be sensitive about it. 🤷♂️
P.s., I'm not a developer of Reloader. Just a user of.
"and it just broke a few of my production work clusters."
I'm not saying Reloader's release process shouldn't change, just saying yours could too. You don't have to be sensitive about it. 🤷♂️
Some checks were not successful
/end
Puts in question your production environment IMO...
Wait a second, you start snarking-off someones production environment...
While someone politely points out your release procedure is the equivalent of hot-garbage.
I think the last person that should be snarking about someones CD pipeline, is the one that has shown to be unable to provide a decent quality CI and release pipeline, isn't it?
There's some confusion here -- I'm a user of Reloader, not a maintainer of, and only voiced an opinion. You don't have to agree or anything.
There's some confusion here -- I'm a user of Reloader, not a maintainer of, and only voiced an opinion. You don't have to agree or anything.
Learn to refrain from commenting on things you truly don't understand.
You mean on things you could have explained better from the get-go instead of being exhaustive ("broke my work clusters" vs "broke my release process"? big difference between the two statements, and likely would've taken the conversation completely differently)? Anyway, to your own hilariously condescending comment, the answer is... No. 😄
Anyway, I'm still in favor. 🙄
Since this is a free and open source project, I think we as a community have a duty to fix problems we see, especially when we are affected ourselves 😀. Therefore, if the releases have been broken twice in the last couple of months the same way, please create a PR that checks against the problem in the release process. We will all benefit.
With that said, I'd appreciate to not have multiple releases per day since our manual process can't handle that anyway and it creates work to find all the changes.