Skip to content

doc: GitHub PRs workflow #8955

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.

Sign up for GitHub

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

Closed
catenacyber wants to merge 1 commit into from
Closed

doc: GitHub PRs workflow #8955

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions doc/userguide/devguide/codebase/contributing/github-pr-workflow.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
GitHub PRs workflow
Copy link
Member

@jasonish jasonish Jun 2, 2023

Choose a reason for hiding this comment

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

GitHub PR Workflow or GitHub Pull Request Workflow.

Copy link
Contributor

@jufajardini jufajardini Jun 2, 2023

Choose a reason for hiding this comment

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

Considering what was mentioned in the last PR, I would go with 'GitHub Pull Requests Workflow' for the title.

Copy link
Contributor Author

@catenacyber catenacyber Jun 3, 2023

Choose a reason for hiding this comment

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

Right

===================

Draft PRs
~~~~~~~~~

A PR should be marked as `draft` if it is not intended to be merged as is,
but is waiting for some sort of feedback.
The author of the PR should explicit with what kind of feedback is expected
(CI/QA run, discussion on the code, etc...)

GitHub filter is ``is:pr is:open draft:true sort:updated-asc``

A draft may be closed if it has not been updated in two months.

Mergeable PRs
~~~~~~~~~~~~~

When a Pull Request is intended to be merged as is, the workflow is the following:
1. get reviewed, and either request changes or get approved
2. if approved, get staged in a next branch (with other PRs), wait for CI validation
(and eventually request changes if CI finds anything)
3. get merged and closed

A newly created PR should match the filter
``is:pr is:open draft:false review:none sort:updated-asc no:assignee``
The whole team is responsible to assign a PR to someone precise within 2 weeks.

When someone gets assigned a PR, the PR should get a review status within 2 weeks:
either changes requested, approved, or assigned to someone else if more
expertise is needed.

GitHub filter for changes-requested PRs is ``is:pr is:open draft:false sort:
updated-asc review:changes-requested``

Such a PR may be closed if it has not been updated in two months.
It is expected that the author creates a new PR with a new version of the patch
as described in :ref:`Pull Requests Criteria <pull-requests-criteria>`.

#TODO filter does not work cf https://github.com/OISF/suricata/pull/8898

GitHub filter for approved PRs that should go in a next branch is ``is:pr is:open
draft:false sort:updated-asc review:approved``

Command to get approved PRs is ``gh pr list --json number,reviewDecision --search
"state:open type:pr -review:none" | jq '.[] | select(.reviewDecision=="")'``

Once in approved state, the PRs are in the responsibility of the merger, along
with the next branches/PRs.
1 change: 1 addition & 0 deletions doc/userguide/devguide/codebase/contributing/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,3 +6,4 @@ Contributing

contribution-process
code-submission-process
github-pr-workflow