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

Do not run jobs when manual_trigger=True #2069

Merged

Conversation

Frawless
Copy link
Contributor

@Frawless Frawless commented May 26, 2023

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:

  • Write new tests or update the old ones to cover new functionality.
  • Update or write new documentation in packit/packit.dev.

Fixes #1806

Related to packit/packit#1984

Merge after packit/packit#1984


RELEASE NOTES BEGIN
 TODO
RELEASE NOTES END

@softwarefactory-project-zuul
Copy link
Contributor

Copy link
Member

@lbarcziova lbarcziova left a 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!

packit_service/worker/jobs.py Outdated Show resolved Hide resolved
@softwarefactory-project-zuul
Copy link
Contributor

Copy link
Member

@lbarcziova lbarcziova left a comment

Choose a reason for hiding this comment

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

regarding the tests, I would add few test cases here... if you need help with that, we can do that :)

we also run pre-commit in the CI that enforces rebased branch, see

@@ -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:
Copy link
Member

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)
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

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

@Frawless Frawless force-pushed the packit-manual-trigger branch 2 times, most recently from 5281e12 to 82299a3 Compare May 29, 2023 10:24
@softwarefactory-project-zuul
Copy link
Contributor

@Frawless Frawless force-pushed the packit-manual-trigger branch 2 times, most recently from 363d581 to 6a1315d Compare May 29, 2023 13:25
Copy link
Member

@mfocko mfocko left a 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 ❤️

Comment on lines 623 to 627
or any(
isinstance(self.event, event_type)
for event_type in MANUAL_EVENTS
)
or job.trigger != JobConfigTriggerType.pull_request
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
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(…)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done :)

Copy link
Member

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?

Copy link
Contributor Author

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")
?

Copy link
Member

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?

Copy link
Member

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)

Copy link
Contributor Author

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.


jobs_matching_trigger.extend(self.check_explicit_matching())

print(jobs_matching_trigger)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
print(jobs_matching_trigger)
logger.debug(jobs_matching_trigger)

In case, it's only for your testing, please don't forget to remove it :)

Copy link
Contributor Author

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!

@softwarefactory-project-zuul
Copy link
Contributor

@softwarefactory-project-zuul
Copy link
Contributor

@softwarefactory-project-zuul
Copy link
Contributor

Copy link
Member

@lbarcziova lbarcziova left a 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 🚀

softwarefactory-project-zuul bot added a commit to packit/packit that referenced this pull request May 29, 2023
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á
@lbarcziova
Copy link
Member

recheck

@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/3b5784b5bc0a40a4ac1720227295f575

✔️ pre-commit SUCCESS in 2m 07s
✔️ packit-service-tests SUCCESS in 2m 36s
✔️ packit-service-tests-openshift SUCCESS in 12m 37s

@Frawless Frawless marked this pull request as ready for review May 29, 2023 19:01
Copy link
Member

@lbarcziova lbarcziova left a 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?

@Frawless
Copy link
Contributor Author

@lbarcziova done, thanks

Signed-off-by: Jakub Stejskal <xstejs24@gmail.com>
@softwarefactory-project-zuul
Copy link
Contributor

@lbarcziova lbarcziova added the mergeit When set, zuul wil gate and merge the PR. label May 30, 2023
@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/7fffb9963948468d877063ddefe1aac4

✔️ pre-commit SUCCESS in 2m 10s
✔️ packit-service-tests SUCCESS in 2m 26s
✔️ packit-service-tests-openshift SUCCESS in 12m 56s

@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded (gate pipeline).
https://softwarefactory-project.io/zuul/t/packit-service/buildset/b61cb63504c644e98f1ac7dbd32e56ea

✔️ pre-commit SUCCESS in 9m 21s

softwarefactory-project-zuul bot added a commit that referenced this pull request Jun 1, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mergeit When set, zuul wil gate and merge the PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow manual-only job triggering
3 participants