-
Notifications
You must be signed in to change notification settings - Fork 229
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
[SURE-9190]New commits from webhook should trigger deployments, but disablePolling for gitrepo prevents new deployments #2969
Comments
I can recreate the issue. Something like this should fix the issue. diff --git a/internal/cmd/controller/gitops/reconciler/gitjob_controller.go b/internal/cmd/controller/gitops/reconciler/gitjob_controller.go
index 549ca958..06cba7e4 100644
--- a/internal/cmd/controller/gitops/reconciler/gitjob_controller.go
+++ b/internal/cmd/controller/gitops/reconciler/gitjob_controller.go
@@ -99,6 +99,7 @@ func (r *GitJobReconciler) SetupWithManager(mgr ctrl.Manager) error {
predicate.GenerationChangedPredicate{},
predicate.AnnotationChangedPredicate{},
predicate.LabelChangedPredicate{},
+ webhookCommitChangedPredicate(),
),
),
).
@@ -1187,3 +1188,20 @@ func result(repoPolled bool, gitrepo *v1alpha1.GitRepo) reconcile.Result {
}
return reconcile.Result{}
}
+
+func webhookCommitChangedPredicate() predicate.Predicate {
+ return predicate.Funcs{
+ UpdateFunc: func(e event.UpdateEvent) bool {
+ oldGitJob, ok := e.ObjectOld.(*v1alpha1.GitRepo)
+ if !ok {
+ return true
+ }
+ newGitJob, ok := e.ObjectNew.(*v1alpha1.GitRepo)
+ if !ok {
+ return true
+ }
+
+ return oldGitJob.Status.WebhookCommit != newGitJob.Status.WebhookCommit
+ },
+ }
+} I'd like to add extra tests, though. |
This adds a new predicate when the webhook commit is changed in the `GitRepo`. It also filters out `Job` events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required. The reconciler already knows when a `Job` is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster. Refers to: rancher#2969 Signed-off-by: Xavi Garcia <[email protected]>
This adds a new predicate when the webhook commit is changed in the `GitRepo`. It also filters out `Job` events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required. The reconciler already knows when a `Job` is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster. Refers to: rancher#2969 Signed-off-by: Xavi Garcia <[email protected]>
* Adds predicate when webhook commit changes This adds a new predicate when the webhook commit is changed in the `GitRepo`. It also filters out `Job` events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required. The reconciler already knows when a `Job` is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster. Refers to: #2969 --------- Signed-off-by: Xavi Garcia <[email protected]> Co-authored-by: Corentin Néau <[email protected]> Co-authored-by: Mario Manno <[email protected]>
* Adds predicate when webhook commit changes This adds a new predicate when the webhook commit is changed in the `GitRepo`. It also filters out `Job` events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required. The reconciler already knows when a `Job` is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster. Refers to: rancher#2969 --------- Signed-off-by: Xavi Garcia <[email protected]> Co-authored-by: Corentin Néau <[email protected]> Co-authored-by: Mario Manno <[email protected]>
* Adds predicate when webhook commit changes This adds a new predicate when the webhook commit is changed in the `GitRepo`. It also filters out `Job` events for creation/deletion, because they add extra reconcile loops that only increase the possibility of race conditions and that are not required. The reconciler already knows when a `Job` is created/deleted because it is the owner and does not need to react upon those 2 events from the cluster. Refers to: #2969 --------- Signed-off-by: Xavi Garcia <[email protected]> Co-authored-by: Corentin Néau <[email protected]> Co-authored-by: Mario Manno <[email protected]>
This is related to #2972 . The screenshot is taken around 9:21 am. Here is the response from the gitjob in rancher server to the azure devops code commit webhook for the same commit.
There is a significant delay between the actual code commit to the actual gitjob for gitrepo bundle update. |
@0xavi0 I have verified this fix again, and it seems to be working fine... |
Tested in with Rancher Steps done:
Screencast.from.31-10-24.12.50.03.mov |
Is there an existing issue for this?
Current Behavior
When disablePolling is enabled in a Git repository, Fleet fetches the latest commit but does not apply it to the deployment. The same behavior is observed with Azure DevOps.
Expected Behavior
when disablePolling set in gitrepo, New commits from webhook should trigger deployments
Steps To Reproduce
simple
path and setdisablePolling: true
Environment
Logs
The text was updated successfully, but these errors were encountered: