You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see that my onprem helm chart repo, harbor, has available webhooks I could target back to argocd when my pipelines push a new/updated helm chart (even if the chart version didn't change), allowing argocd to instantly deploy the new helm chart. So, I decided to take a look at argocd to see if the webhook code might be easily enhanced, or possibly, already have a section for responding to helm chart updates.
The code I found is all in one file, and from an initial look, seems to have a lot of hard coded values in it. It seems perfectly written to handle what I suspect are the most common use cases.
However, while motivated to enhance the code to work with harbor helm charts... and perhaps to enhance the code to work with helm chart webhooks in general, with harbor being one of many potential supported apps, I have to say that I feel a sense of hesitation given that everything is written in one long file. If feels like I might break something.
It feels like the different webhooks should be in their own files... one for gitlab, one for github, etc ... then I could enhance things by adding 'harbor', and it would be isolated and be less likely to interfere with other things.
Additionally, it almost seems like we could maybe even just use some json files which indicate a source url, a regex pattern, and action to take in response (pull new helm chart, pull new image, refresh, hard refresh) ... rather than have hard-coded values. I don't know all the use cases, but could that work? Then we could have one .json file per host (e.g. github) with an array of things it could do (webhooks it can respond to). That seems like it would be way easy to support and enhance.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I see that my onprem helm chart repo, harbor, has available webhooks I could target back to argocd when my pipelines push a new/updated helm chart (even if the chart version didn't change), allowing argocd to instantly deploy the new helm chart. So, I decided to take a look at argocd to see if the webhook code might be easily enhanced, or possibly, already have a section for responding to helm chart updates.
The code I found is all in one file, and from an initial look, seems to have a lot of hard coded values in it. It seems perfectly written to handle what I suspect are the most common use cases.
However, while motivated to enhance the code to work with harbor helm charts... and perhaps to enhance the code to work with helm chart webhooks in general, with harbor being one of many potential supported apps, I have to say that I feel a sense of hesitation given that everything is written in one long file. If feels like I might break something.
It feels like the different webhooks should be in their own files... one for gitlab, one for github, etc ... then I could enhance things by adding 'harbor', and it would be isolated and be less likely to interfere with other things.
Additionally, it almost seems like we could maybe even just use some json files which indicate a source url, a regex pattern, and action to take in response (pull new helm chart, pull new image, refresh, hard refresh) ... rather than have hard-coded values. I don't know all the use cases, but could that work? Then we could have one .json file per host (e.g. github) with an array of things it could do (webhooks it can respond to). That seems like it would be way easy to support and enhance.
What do you folks think?
Beta Was this translation helpful? Give feedback.
All reactions