Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Group pending dependency updates #4336

Closed
premun opened this issue Jan 16, 2025 · 2 comments
Closed

Group pending dependency updates #4336

premun opened this issue Jan 16, 2025 · 2 comments
Assignees
@dkurepa
Milestone
Implement support...

Comments

@premun
Copy link
Member

premun commented Jan 16, 2025 •
edited by adamzip
Loading

Context

When a dependency PR is opened and its builds are currently running, PCS does not update the PR with new updates but queues the update for later and tries again. This means that several updates can get queued. The problem is that right now, they will get applied one by one in a FIFO manner.
Instead, the latest should be applied only.

Goal

  • Make sure that the latest queued (pending) update is applied instead of the one next in line.
    The updates are queued as delayed messages in the background queue and appear one by one. PCS has no chance knowing there's more.
    This will probably mean writing into Redis what the latest pending update is and ignoring the other updates.
    So when we are delaying an update, we need to write the build number/time into Redis and when we're processing the pending updates, we should just apply the newest. This can be either done by waiting for the matching queue message or performing the latest update with the first message that comes for that subscription.
  • It should also be possible to write a unit test for it (DependencyFlow.Tests project)
@premun
Copy link
Member Author

premun commented Jan 17, 2025

Maybe the best would be to just store the build ID in Redis and:

  • When we are processing a queue message, compare which ID (Redis vs queue message) is newer and use that one.
  • If PR can be updated, use this ID to update the PR.
  • Otherwise store the newest ID in Redis and queue the pending update.

@premun premun moved this to Ready in .NET Unified Build Jan 23, 2025
@dkurepa dkurepa mentioned this issue Feb 5, 2025
Merged
dkurepa added a commit that referenced this issue Feb 10, 2025
@dkurepa @premun
Group subscription updates (#4422)
5ffc662 
<!-- Link the GitHub or AzDO issue this pull request is associated with.
Please copy and paste the full URL rather than using the
dotnet/arcade-services# syntax -->
#4336
This PR makes the service group dependency updates by keeping track of
the commit that was in the latest subscription trigger.
For example, let's say we trigger a subscription (we'll call it trigger
1) that has an already existing PR, but that PR can't be updated. We set
a reminder to try again later. Now let's say we trigger the subscription
again (trigger 2), again, but the PR is still not updatable.
This PR makes it so that the update caused by the trigger 1 doesn't get
processed, because a newer update from trigger 2 should be processed
next

---------

Co-authored-by: Přemek Vysoký <[email protected]>
@dkurepa
Copy link
Member

dkurepa commented Feb 10, 2025

Feature implemented in PR above

@dkurepa dkurepa closed this as completed Feb 10, 2025
@github-project-automation github-project-automation bot moved this from Ready to Done in .NET Unified Build Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dkurepa dkurepa

Labels
None yet
Projects
.NET Unified Build
Status: Done
Milestone
Implement support for codeflow subscr...
Development

No branches or pull requests
2 participants
@premun @dkurepa