-
Notifications
You must be signed in to change notification settings - Fork 208
Implement Event watcher #1411
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
Implement Event watcher #1411
Conversation
|
The following ISSUES will be created once got merged. If you want me to skip creating the issue, you can use Details1. Retrieve the data from the control-plane.This was created by todo plugin since "FIXME:" was found in ad24180 when #1411 was merged. cc: @nakabonne. |
pipecd-bot
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
Code coverage for golang is
|
ad24180 to
9a250c4
Compare
**What this PR does / why we need it**: This PR adds a new `apistore` for Events according to @nghialv 's [suggestion](#1410 (comment)). It allows us to reduce communication number by caching the latest events. This will be used by #1411 at first. **Which issue(s) this PR fixes**: Ref #1381 **Does this PR introduce a user-facing change?**: <!-- If no, just write "NONE" in the release-note block below. --> ```release-note NONE ``` This PR was merged by Kapetanios.
| continue | ||
| } | ||
| // Put it into the change list. | ||
| newYml, err := yamlprocessor.ReplaceValue(yml, r.YAMLField, latestEvent.Data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case the users configured multiple fields for the same file, will this override the old changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that commit will happen conflict and end with failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I assumed it doesn't happen if the latest values are the same. It happens when only the latest values are different from each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I just got what you mean. No. it always override the original content, defined in Git.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of my decisions are based on the rule that never makes a change that crosses lines, but you know what I mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I totally got what you're most worried about. Yes, you're right. That can revert previous changes. Let me re-think it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we can simply solve it by editing a local file inside this loop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. That is what I was talking about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha, finally I caught up.
I feel like we can simply solve it by editing a local file inside this loop.
I'm now inspecting if there are some issues with this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we have no problem with it, so applied it. PTAL 😄
| if err != nil { | ||
| return nil, fmt.Errorf("failed to replace value at %s with %s: %w", r.YAMLField, latestEvent.Data, err) | ||
| } | ||
| if err := ioutil.WriteFile(path, newYml, os.ModePerm); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have just realized that we have to save it in memory instead of writing to the local path.
Because writing it back to the local path will cause an error while doing the next pulls ??
(The data inside the repo must be read-only.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So at line 215, checking it in the changes map before loading it from the local path looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right! using cache looks good. Alternatively, I think we can leverage the temp repo because we use it when pushing. We can use it when making changes as well
https://github.com/pipe-cd/pipe/pull/1411/files#diff-60908ffb7e37bfc3692d8c4cace4be91d53bccf9a549fb91ea30b70387abd9cfR191
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Totally I misunderstood that we're using tmpRepo when making changes.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... using tmp repo makes the logic simple. But on the dark side, copying the directory happens every time no matter commits exists. After thinking about that, I'm beginning to think the way to check changes you suggested is more appropriate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, checking changes looks better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good. Let me do so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hold on, I found it is still likely to be overwritten when processing other events. The changes is reset for each event. So looks like it's safer to use tmpRepo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. lol. So let's update the local data. And please change the function name to match its new behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. The current one is absolutely not appropriate.
|
Thanks to deeper discussion, maybe we have the best one. Could you take a look? |
|
Nice. |
|
Let's merge this PR. |
|
ops, sorry I have not noticed this PR 🙇♂️ |
|
@khanhtc1202 No problem. I just want to merge it for a nice weekend. lol. |
|
Thank you both of you. It's going to make for a good weekend 😃 |
|
Have a nice weekend. 🏃♂️ |

What this PR does / why we need it:
Add Event watcher, a piped component that periodically fetches the latest Event from the
eventstoreto compare the value with one in the git repository.Most core logic is borrowed from
imagewatcherbeing already. And soon-to-be enables this as another PR.Which issue(s) this PR fixes:
Ref #1381
Does this PR introduce a user-facing change?: