New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
retry-on-snapshot-warnings - not working as expected on separate snapshot/review workflows #632
Comments
Hi @felickz, I really appreciate the reproduction and detailed logs! Much of this does sound very strange to me, but one thing sticks out as especially strange:
Can you clarify that this applies truly at any point? In other words, if you wait for a very long time (like an hour), does it still retry at least once before succeeding? |
In the sample is showed - it was @ 15 mins:
In a previous repro - i had run another time with 5 minutes between with similar behavior, but rerun did not mention any no snapshots found - (initial run):
|
@febuiles I don't have a ton of time to devote to this and nothing's really jumping out at me, but I do have a vague suspicion that this may be related to https://github.com/github/dependency-snapshots-api/pull/615. I thought that would only change the way we handle new canonical snapshots and that shouldn't matter here, but if there's some reason why it's taking a while for new snapshots to be written to the |
@juxtin thanks for the extra feedback 🙇 @jamisonhyatt any ideas if the locks-related change could be having an impact downstream like this? Does any of this look suspicious to you? |
I have another oddity where it seems submission actions like
Then the DR action (with Is this something the toolkit is intended to handle? I am not totally clear what this sha is showing me, this might be a temporary hidden merge branch that is used to check "This branch has no conflicts with the base branch"? Would it make any sense for DR to be also looking at this SHA for snapshot submissions? |
Need to do research if the issue is with the backend service or potential race condition |
I also encountered this problem, only I'm using the With an added known vulnerable dependency I could re-run the review workflow at least 3 times all ending in a timeout and no vulnerabilites reported. The timeout was set to 10 minutes and the three times were run consecutively ... Then, after waiting for maybe 30+ minutes (searching for answers and coming back for debug-logs), the re-runs suddenly started consistently reporting a "vulnerable dependency detected". It reminded me of how replication lag behaves as the snapshot propagates across data stores .. I couldn't find an option for failing the build on timeouts, and with the green checkmark on the PR I doubt many people will study the logs to see if it all ran as they expected. Should it fail, or at least give a warning, when the timeout expires and there's still no snapshot? |
Hello everyone, I believe this issue with the Following the documentation for gradle-build-action, setup-gradle, and dependency-submission, I've configured the following workflow files:
However, even though the second step has been completed, the
Additionally, the I kindly request the community to address this issue as soon as possible. My PR, which I've invested considerable research time into, is currently stalled because of this issue. Thank you very much. |
Using
retry-on-snapshot-warnings
for a submission from a different workflow as described in the docs. If the snapshot upload completes during the phase where the review task is waiting for an upload against the head SHA - none of the retries pick it up. If you re-run the review workflow it picks up the newly committed snapshot.On Push:
On PR:
Retry timeout exceeded. Proceeding...
after 4m 37s)Submission Workflow
63d50c7154fc8bfb6ce9173f0d0edfe5f31d810f
Snapshot submission to
"sha": "63d50c7154fc8bfb6ce9173f0d0edfe5f31d810f"
+"ref": "refs/heads/feature/FSharp-Data"
... and completes within a second at
2023-12-04T18:10:55.414Z
:Review Workflow
Review Workflow - run 2
Most interesting is that re-running dependency review task at any point in the future succeeds after 2 tries (doesnt mention a snapshot found but looking at the detections it has found dependencies that only exist in the snapshot manifest):
The text was updated successfully, but these errors were encountered: