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.

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

Fix requeue for git commit tracking #763

Merged
merged 4 commits into from
Nov 27, 2024
Merged

Fix requeue for git commit tracking #763

merged 4 commits into from
Nov 27, 2024

Conversation

blampe
Copy link
Contributor

@blampe blampe commented Nov 26, 2024

Fixes a bug where we were accidentally cancelling a requeue when we intended to poll again after a minute.

Fixes #762.

// Reconcile every resyncFreq to check for new commits to the branch.
pollFreq := resyncFreq(instance)
log.Info("Commit hash unchanged. Will poll for new commits.", "pollFrequency", pollFreq)
requeueAfter = min(requeueAfter, pollFreq)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

requeueAfter defaults to 0 so this min was always disabling the requeue.

Copy link
Contributor

@EronWright EronWright Nov 26, 2024

Choose a reason for hiding this comment

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

Good find, that's totally the problem.

Regarding the duplication of code here, I think my rationale is that the resync frequency is today unduly coupled between branch tracking and the periodic resync, ie. the resyncFrequencySeconds. I anticipate new git-specific fields for branch tracking, such that one could say "check the branch every minute, and do a re-sync (for drift detection) every hour".

Copy link
Contributor

Choose a reason for hiding this comment

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

I took the liberty of reverting the optimization, for clarity.

@blampe blampe requested a review from EronWright November 26, 2024 22:57
Copy link

codecov bot commented Nov 26, 2024

Codecov Report

Attention: Patch coverage is 37.50000% with 5 lines in your changes missing coverage. Please review.

Project coverage is 50.71%. Comparing base (b7c71da) to head (153f9c8).
Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
...tor/internal/controller/pulumi/stack_controller.go 37.50% 5 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #763      +/-   ##
==========================================
- Coverage   50.75%   50.71%   -0.04%     
==========================================
  Files          30       30              
  Lines        4175     4180       +5     
==========================================
+ Hits         2119     2120       +1     
- Misses       1872     1876       +4     
  Partials      184      184              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

// Reconcile every resyncFreq to check for new commits to the branch.
pollFreq := resyncFreq(instance)
log.Info("Commit hash unchanged. Will poll for new commits.", "pollFrequency", pollFreq)
requeueAfter = min(requeueAfter, pollFreq)
Copy link
Contributor

@EronWright EronWright Nov 26, 2024

Choose a reason for hiding this comment

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

Good find, that's totally the problem.

Regarding the duplication of code here, I think my rationale is that the resync frequency is today unduly coupled between branch tracking and the periodic resync, ie. the resyncFrequencySeconds. I anticipate new git-specific fields for branch tracking, such that one could say "check the branch every minute, and do a re-sync (for drift detection) every hour".

if instance.Status.LastUpdate.State == shared.FailedStackStateMessage {
requeueAfter = max(1*time.Second, time.Until(instance.Status.LastUpdate.LastResyncTime.Add(cooldown(instance))))
}
if sess.stack.ContinueResyncOnCommitMatch {
// Schedule another poll if ContinueResyncOnCommitMatch is set, for drift detection or to maintain dynamic resources.
if instance.Status.LastUpdate.State == shared.SucceededStackStateMessage && sess.stack.ContinueResyncOnCommitMatch {
Copy link
Contributor

@EronWright EronWright Nov 27, 2024

Choose a reason for hiding this comment

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

The "ContinueResyncOnCommitMatch" polling loop should activate only when the last update was successful. Otherwise, the backoff loop should prevail (and is likely a shorter interval).

Meanwhile the source tracking loop should be active regardless of the last update. And it should adjust the requeueAfter value downward only.

@EronWright EronWright merged commit 09f8484 into master Nov 27, 2024
7 checks passed
@EronWright EronWright deleted the blampe/git-resync branch November 27, 2024 21:01
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.

New commits not detected
2 participants