Add research about Jotnar/Ymir triggering rearchitecture#230
Add research about Jotnar/Ymir triggering rearchitecture#230lbarcziova wants to merge 4 commits intopackit:mainfrom
Conversation
|
There is another potential option for a trigger, the automation button in the new Jira: |
|
@nforro good catch! The triggering mechanism seems to be indeed via the Automation Rules, if I click from there for Packit issues, I get to https://redhat.atlassian.net/jira/software/c/projects/PACKIT/settings/automate. And it would be just different kind of trigger, |
Fixes PACKIT-4842 Assisted-By: Claude Opus 4.6 <noreply@anthropic.com>
Assisted-By: Claude Opus 4.6 <noreply@anthropic.com>
lbarcziova
force-pushed
the
ymir-rearchitecture-design
branch
from
dbd9c64 to
b03682d
Compare
Assisted-By: Claude Opus 4.6 <noreply@anthropic.com>
| - Author validation — check Jira group membership before processing | ||
| - Queue routing — push to appropriate Redis queue based on action and branch | ||
| - Acknowledgment — post a Jira comment confirming the command was received | ||
| - Deduplication — track processed commands to avoid re-processing on retries |
There was a problem hiding this comment.
In this scenario, we could also re-use Celery. It could simplify the retrying mechanism (otherwise we should implement it), also I think it could solve the deduplication.
There was a problem hiding this comment.
Celery seems like the most straightforward option.
There was a problem hiding this comment.
Great point @majamassarini, Celery would definitely be useful for autorefries etc. For launching the service for early adopters and with the expected load being low since workflows are opt-in, I would start with what we have. But we should keep this on the radar for the following months, especially if the load/workflow grow.
| - Result set grows over time, needs time-based filtering (e.g., `AND updated >= -1d`) | ||
| — but `updated` catches any issue update, not just new @Ymir mentions, producing | ||
| false positives that still require comment-by-comment inspection |
There was a problem hiding this comment.
It would help if we had estimates on how many issues are changed in jira per day. That way we would have some idea of an upper bound.
Our worst case scenario, is an eternal, continuously updated task, where Ymir was mentioned once. Provided we can avoid invoking LLM to determine response, we should be able to handle even cases like this.
There was a problem hiding this comment.
I'm sure that thousands of RHEL jiras are changed every day.
There was a problem hiding this comment.
Thousands should be manageable, provided that we filter out cases when Ymir is not actually required. For example, if the change is not a new comment invoking Ymir, we ignore the change and don't check it again for some period of time.
Assisted-By: Claude Opus 4.6 <noreply@anthropic.com>
| but triage can't paste a one-click follow-up action. With CLI, triage pastes a pre-filled | ||
| command that the user copy-pastes to trigger backport/rebase. Both can coexist. | ||
|
|
||
| **To decide**: Which to start with — `/ymir` CLI or manual trigger forms (or both). |
There was a problem hiding this comment.
To me the /ymir CLI sounds best, and i think packagers would appreciate it for specific actions, if it does not bring any big implementation complexities (e.g. not sure how hard it is to listen to certain comments in Jira). Perhaps @ymir rebase --version... format would be most appropriate. It would allow us to listen for ymir commands effectively and have CLI style interface.
|
|
||
| --- | ||
|
|
||
| ### Option C: Jira Automation Rules |
8 participants
Fixes PACKIT-4842
Assisted-By: Claude Opus 4.6 noreply@anthropic.com