Skip to content

SRVLOGIC-1151 | Add run-with-retry helper for resilient Go dependency resolution - #457

Draft
jankrystof-ibm wants to merge 1 commit into
mainfrom
SRVLOGIC-1151__resilient-go-dependency-resolution-in-kie-tools-ci
Draft

jankrystof-ibm wants to merge 1 commit into
mainfrom
SRVLOGIC-1151__resilient-go-dependency-resolution-in-kie-tools-ci

Conversation

@jankrystof-ibm

@jankrystof-ibm jankrystof-ibm commented Aug 24, 2026 •

Copy link
Copy Markdown

ticket: https://redhat.atlassian.net/browse/SRVLOGIC-1151

CI bootstrap occasionally aborts when Go dependency resolution (go work sync / go mod tidy) hits a transient network failure, e.g. checksum verification against sum.golang.org. The newly introduced package wraps the resolution step in the install hooks with a bounded retry+backoff wrapper so a transient outage no longer kills the whole job immediately but it enables several retries.

New package @kie-tools-scripts/run-with-retry ensures 5 attempts with backoff 5/15/30/60s between attempts (last value repeats, so raising --retries keeps spacing later attempts by a minute). On exhaustion it exits with the original exit code, so non-transient failures still surface and are not masked.

@jankrystof-ibm

Copy link
Copy Markdown
Author

After the CI run I see

  • The helper is wired in and functional in CI :: Build - confirmed by the log
  • The happy path passed (the network was healthy, so Attempt 1/5 -> Succeeded for all of them). The retry/backoff branches logically did not trigger (there was no transient outage)

@baldimir

Copy link
Copy Markdown

Adding @fantonangeli to reviewers, who is better with Javascript.

@fantonangeli fantonangeli left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I would just double check the lockfile

Comment thread pnpm-lock.yaml
jest:
specifier: ^29.7.0
version: 29.7.0(@types/node@24.13.3)(node-notifier@8.0.2)(ts-node@10.9.2(@swc/core@1.3.92)(@types/node@24.13.3)(typescript@5.9.3))
version: 29.7.0(@types/node@26.1.1)(node-notifier@8.0.2)(ts-node@10.9.2(@swc/core@1.3.92)(@types/node@26.1.1)(typescript@5.9.3))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all these @types/node 24.13.3 → 26.1.1 lockfile changes should not be expected.
Can you try to re-generate it?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, those types need to stay as before, aligned with the supported node version.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jankrystof-ibm could you please take a look?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may leave it as it is. I have the same problem when regenerating the lock file. Those types/node should be compatible. We have ^24.0.11 in the package.json and these are supposed to be compatible with it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I'm changing my review

@jankrystof-ibm
jankrystof-ibm marked this pull request as draft September 11, 2026 06:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants