Skip to content

Commit

Permalink
ci(mergify): strip merge commit HTML comments
Browse files Browse the repository at this point in the history
  • Loading branch information
michaelfig authored and mhofman committed Jun 20, 2024
1 parent ef9357e commit f04d8eb
Show file tree
Hide file tree
Showing 2 changed files with 12 additions and 22 deletions.
22 changes: 4 additions & 18 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,33 +8,19 @@ closes: #XXXX
refs: #XXXX

## Description

<!-- Add a description of the changes that this PR introduces and the files that
are the most critical to review.
-->
<!-- Add a description of the changes that this PR introduces and the files that are the most critical to review. -->

### Security Considerations

<!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls?
-->
<!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? -->

### Scaling Considerations

<!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? -->

### Documentation Considerations

<!-- Give our docs folks some hints about what needs to be described to downstream users.
Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users?
-->
<!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? -->

### Testing Considerations

<!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet?
-->
<!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? -->

### Upgrade Considerations

<!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
12 changes: 8 additions & 4 deletions .mergify.yml
Original file line number Diff line number Diff line change
@@ -1,7 +1,11 @@
# Linear queue for the main branch.
queue_rules:
- name: main
conditions:
commit_message_template: |-
{{ title }} (#{{ number }})
{{ body | trim }}
queue_conditions:
- base=master
# Require integration tests before merging only
- or:
Expand Down Expand Up @@ -30,7 +34,7 @@ pull_request_rules:
actions:
queue:
name: main
method: merge
merge_method: merge
- name: rebase updates then merge to master
conditions:
- base=master
Expand All @@ -49,7 +53,7 @@ pull_request_rules:
actions:
queue:
name: main
method: merge
merge_method: merge
update_method: rebase
- name: squash to master
conditions:
Expand All @@ -69,4 +73,4 @@ pull_request_rules:
actions:
queue:
name: main
method: squash
merge_method: squash

0 comments on commit f04d8eb

Please sign in to comment.