Introduce some kind of retry for fetch/git types fo conmsumption

[Itxaka]

Me again, sorry about that :D

We been running bump and are seeing how weak is the internet infra as several sources in our bumpfile are failing randomly.

Now I though it would be nice to have some kind of retry so it retries sources, maybe with a back off.

So when running it unattended via CI, it would just not fail but retry a bit in case its a temporary thing

I think this matches really good with teh other request for non fail when a single entry fail, as it complements it greatly.

Not sure how to implement it though, if it could be part of the filter, the rule, an extra field for options or a global thing.

[wader]

Me again, sorry about that :D

No worries :)

We been running bump and are seeing how weak is the internet infra as several sources in our bumpfile are failing randomly.

Now I though it would be nice to have some kind of retry so it retries sources, maybe with a back off.

So when running it unattended via CI, it would just not fail but retry a bit in case its a temporary thing

I think this matches really good with teh other request for non fail when a single entry fail, as it complements it greatly.

Not sure how to implement it though, if it could be part of the filter, the rule, an extra field for options or a global thing.

Start with some "sensible" default values for retry and backoff? possible overridable with env variables or argument etc?

The simplest as you mentioned is probably to rely on filter error and keep track of some backoff state per pipeline and retry them. One optimizations one could do later is to either add retry inside some filters that might have transient/soft errors or another way could be to make it possible for a filter to return an error that is somehow decorated if the error retry-able or not.

BTW, how do you use bump? via CLI or thru github action?

[Itxaka]

Me again, sorry about that :D

No worries :)

We been running bump and are seeing how weak is the internet infra as several sources in our bumpfile are failing randomly.
Now I though it would be nice to have some kind of retry so it retries sources, maybe with a back off.
So when running it unattended via CI, it would just not fail but retry a bit in case its a temporary thing
I think this matches really good with teh other request for non fail when a single entry fail, as it complements it greatly.
Not sure how to implement it though, if it could be part of the filter, the rule, an extra field for options or a global thing.

Start with some "sensible" default values for retry and backoff? possible overridable with env variables or argument etc?

The simplest as you mentioned is probably to rely on filter error and keep track of some backoff state per pipeline and retry them. One optimizations one could do later is to either add retry inside some filters that might have transient/soft errors or another way could be to make it possible for a filter to return an error that is somehow decorated if the error retry-able or not.

BTW, how do you use bump? via CLI or thru github action?

Currently via github action but using the cli though. As having the full action means running a docker image that we cant control, its easier to just install the bump cli and run it under our control to avoid potentially exposing redentials and such.

https://github.com/kairos-io/hadron/actions/workflows/autobumper.yml
https://github.com/kairos-io/hadron/blob/main/.github/workflows/autobumper.yml

We have to unset the GITHUB_ACTION before running bump update , otherwise it will try to act like its being called as the actual action, and we dont want that, we want to generate the diff itself and then do the fork and push the changes ourselves :)

[wader]

Currently via github action but using the cli though. As having the full action means running a docker image that we cant control, its easier to just install the bump cli and run it under our control to avoid potentially exposing redentials and such.

https://github.com/kairos-io/hadron/actions/workflows/autobumper.yml https://github.com/kairos-io/hadron/blob/main/.github/workflows/autobumper.yml

We have to unset the GITHUB_ACTION before running bump update , otherwise it will try to act like its being called as the actual action, and we dont want that, we want to generate the diff itself and then do the fork and push the changes ourselves :)

I see, that makes sense, also now i see how many bump configs you have 😬 If you really wanted to use the action i guess you could use a tag or build the action image yourself. But i think it would make sense to make bump more CI agnostic, not sure how yet.

About GITHUB_ACTION, that feels like something that would be fixed. If i understand the docs correctly maybe it can look at GITHUB_ACTIONS (with an ending S) instead? https://docs.github.com/en/actions/reference/workflows-and-actions/variables?#default-environment-variables

[wader]

Now bump looks for GITHUB_ACTIONS instead #200 which seems to work and should not be set for a run-step. I guess it will still be a problem if someone uses bump via a uses action somehow