-
Notifications
You must be signed in to change notification settings - Fork 48
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
Do not run jobs when manual_trigger=True #2069
Do not run jobs when manual_trigger=True #2069
Conversation
Build failed. ✔️ pre-commit SUCCESS in 2m 11s |
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.
thanks again for the contribution!
Build failed. ❌ pre-commit FAILURE in 2m 13s |
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.
packit_service/worker/jobs.py
Outdated
@@ -615,7 +631,8 @@ def get_jobs_matching_event(self) -> List[JobConfig]: | |||
) | |||
and job not in jobs_matching_trigger | |||
): | |||
jobs_matching_trigger.append(job) | |||
if not job.manual_trigger or self.event in MANUAL_EVENTS: |
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.
as I am looking into the list of MANUAL_EVENTS, we could reduce the events to only AbstractCommentEvent
, and CheckRerunEvent
there and use any(isinstance(self.event, event_type) for event_type in MANUAL_EVENTS)
here to count with inheritance
@@ -77,6 +78,7 @@ | |||
@reacts_to(PushGitlabEvent) | |||
@reacts_to(MergeRequestGitlabEvent) | |||
@reacts_to(AbstractPRCommentEvent) | |||
@reacts_to(AbstractIssueCommentEvent) |
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.
we want to react only to pull request comments for running the Testing Farm
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 understood that some of the users want to trigger it from the issues. Is that something we will deal with in another pr? Or I just misunderstood 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.
we allow retriggering from issues for the propose_downstream
job
5281e12
to
82299a3
Compare
Build failed. ❌ pre-commit FAILURE in 2m 08s |
363d581
to
6a1315d
Compare
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.
LGTM :) Thanks a lot for your contribution ❤️
packit_service/worker/jobs.py
Outdated
or any( | ||
isinstance(self.event, event_type) | ||
for event_type in MANUAL_EVENTS | ||
) | ||
or job.trigger != JobConfigTriggerType.pull_request |
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.
or any( | |
isinstance(self.event, event_type) | |
for event_type in MANUAL_EVENTS | |
) | |
or job.trigger != JobConfigTriggerType.pull_request | |
or job.trigger != JobConfigTriggerType.pull_request | |
or any( | |
isinstance(self.event, event_type) | |
for event_type in MANUAL_EVENTS | |
) |
Just my OCD, I guess, but .trigger
seems to be something that can be resolved faster than the any(…)
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.
Done :)
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.
is the job.trigger != JobConfigTriggerType.pull_request
acutally needed?
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 user will specify manual_trigger=True
in jobs that do not care about the option we should skip it...now I am thinking if checking job type is a better option or not 🤔 something like job.type != JobType.tests
...or is this all handled by decorators here
@run_for_comment(command="test") |
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, the decorators should take care of the mapping itself
my thinking was that by omitting that part of the condition this could be used generally for any job (e.g. also for the mentioned propose-downstream) without binding it to the testing farm job (+ the docs would explain the option properly); @mfocko WDYT?
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.
+1 for having it for all commands; if it gets used in a job that is not easily run via comment, it's a user error IMO, not an issue 🤷
Also I looked around, not only at the diff, I would probably merge it with the if
in which it's wrapped now; keeping the last check of the if
above at the end even after merging it in one condition. (It just seems like an unnecessary indentation)
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, I updated the code and tests.
packit_service/worker/jobs.py
Outdated
|
||
jobs_matching_trigger.extend(self.check_explicit_matching()) | ||
|
||
print(jobs_matching_trigger) |
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.
print(jobs_matching_trigger) | |
logger.debug(jobs_matching_trigger) |
In case, it's only for your testing, please don't forget to remove 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.
Ye just leftover from debugging, removed!
Build failed. ✔️ pre-commit SUCCESS in 2m 11s |
Build failed. ✔️ pre-commit SUCCESS in 2m 11s |
Build failed. ✔️ pre-commit SUCCESS in 2m 11s |
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.
LGTM once the tests are green 🚀
Add new option manual_trigger to packit schema This PR adds new option manual_trigger into Packit schema to allow users to trigger Packit jobs manually. Service integration done in packit/packit-service#2069 Write new tests or update the old ones to cover new functionality. Update or write new documentation in packit/packit.dev. Fixes packit/packit-service#1806 RELEASE NOTES BEGIN Packit now supports automatic ordering of ☕ after all checks pass. RELEASE NOTES END Reviewed-by: Laura Barcziová
recheck |
Build succeeded. ✔️ pre-commit SUCCESS in 2m 07s |
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.
nice, thanks!!
could you please squash the commits here as well?
e4935b1
to
e6247a2
Compare
@lbarcziova done, thanks |
Signed-off-by: Jakub Stejskal <xstejs24@gmail.com>
Build failed. ❌ pre-commit FAILURE in 2m 11s |
e6247a2
to
6bb2c6c
Compare
Build succeeded. ✔️ pre-commit SUCCESS in 2m 10s |
Build succeeded (gate pipeline). ✔️ pre-commit SUCCESS in 9m 21s |
Fix results events reporting from packit-service Fixes issue introduced in #2069. When manual_trigger=True the results event are filtered and the results are not propagated properly back to je github/gitlab. Write new tests or update the old ones to cover new functionality. Reviewed-by: Laura Barcziová Reviewed-by: Jakub Stejskal <xstejs24@gmail.com> Reviewed-by: František Lachman
This PR adds logic that when user specify
manual_trigger: True
in job definition, the handler will not consider this job as executable automatically, only via comment.TODO:
packit/packit.dev
.Fixes #1806
Related to packit/packit#1984
Merge after packit/packit#1984
RELEASE NOTES BEGIN
 TODO
RELEASE NOTES END