Answers: <p>You can still use pull requests with <a href="https://trunkbaseddevelopment.com/" rel="nofollow noreferrer">Trunk-Based Development</a>. Especially with larger teams, using <a href="https://trunkbaseddevelopment.com/short-lived-feature-branches/" rel="nofollow noreferrer">short-lived feature branches</a>, you would open a pull request into the trunk, which would start the build process. Depending on your environment and desire to have rapid merges, you could merge the pull request automatically, perhaps based on things like no new style violations, sufficient code coverage, tests pass, and no new static analysis violations, and defer the human review for later.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-05-04T12:09:25.930Z
Answers: Is that still trunk based though? Your suggestion sounds like people should create feature branches rather than committing directly to main, which is our current situation.
Answers: James Geddes
Answers: CC BY-SA 4.0
Answers: 2022-05-04T13:27:26.057Z
Answers: @JamesGeddes Did you see what site the links point to? Yes, that's from the definition of trunk-based development.
Answers: Thomas Owens
Answers: CC BY-SA 4.0
Answers: 2022-05-04T14:19:35.627Z
Answers: I did, however not committing to main is surely not pure trunk based dev https://youtu.be/ASOSEiJCyEM
Answers: James Geddes
Answers: CC BY-SA 4.0
Answers: 2022-05-04T14:56:48.407Z
Answers: @JamesGeddes In that video, Dave Farley is talking about human-gated pull requests. I mentioned this in my answer - you can still use pull request tools (like GitHub, Bitbucket, and perhaps others) to perform automated checks and automatically merge, while deferring human reviews for later. However, there is no way to both commit to trunk _and_ run your pipeline before a merge. You need to decide what is more important - waiting a short period of time (hopefully minutes) to get your automated results and merging or integrating faster and getting results later.
Answers: Thomas Owens
Answers: CC BY-SA 4.0
Answers: 2022-05-04T15:00:22.927Z
Answers: Ah with you. I thought Dave Farley is saying that all PRs are always evil. Automated testing ftw.
Answers: James Geddes
Answers: CC BY-SA 4.0
Answers: 2022-05-04T15:06:29.370Z
Answers: @JamesGeddes I'd have to rewatch that video to be 100%, but I watched it when it came out (his channel is great). I highly doubt he'd object to your pipeline blocking a merge, but I suspect he's say that you should be aiming to get your branch into main (meaning it passes the pipeline) within a day or two of opening it. That also has implications for how long your pipeline should take to execute - 10 or 15 minutes could be a very long pipeline. You can always defer more to post-merge - it's all about balancing ensuring quality, reducing risk, and letting people use your changes to buildon.
Answers: Thomas Owens
Answers: CC BY-SA 4.0
Answers: 2022-09-07T20:11:07.803Z
Answers: @JamesGeddes From a purely Git perspective, this debate is kind of funny. In Git, a branch is a pointer to a commit that has a name. If the "trunk" is called `main` on the remote, and you call your local branch `main`, then it's TBD. If you rename your local branch to `my-branch` then TBD magically changes into "Feature Branch Workflow", which is also known as GitHub Flow and many other popular CI workflows.  PR's are fine, just temporarily rename (or copy) your local `main` to something else and push it out so you can use the PR tool functionality, if you want to.
Answers: TTT
Answers: CC BY-SA 4.0
Answers: 2022-05-04T09:41:33.250Z
Answers: 2022-05-04T09:41:33.250Z
Answers: Thomas Owens
Body: <p>Currently, we use a simple branching strategy, with a single main branch and one layer of feature branches; no branches on branches on branches. We also have many pipelines that run against each PR to check the code before it is merged to the main branch, including but not limited to,</p>
  <ul>
  <li>code quality</li>
  <li>linting</li>
  <li>security assurance</li>
  </ul>
  <p>In a trunk-based approach, how does one run these tests before code is merged, without a PR?</p>
  <p>I have seen <a href="https://devops.stackexchange.com/q/9855/30208">Trunk Based Development - release branch testing</a> but it did not fully answer my question. Thanks in advance for your patience with a n00b question :D</p>
  
Tags: <git><automation><testing><tdd>
Title: How can you do pre-merge testing in trunk based development?
UserDisplayName: James Geddes
ThreadText: # How can you do pre-merge testing in trunk based development?
  
  (Asked by: username_0 on 2022-05-04)
  
  Currently, we use a simple branching strategy, with a single main branch and one layer of feature branches; no branches on branches on branches. We also have many pipelines that run against each PR to check the code before it is merged to the main branch, including but not limited to,
  
  * code quality
  * linting
  * security assurance
  
  In a trunk-based approach, how does one run these tests before code is merged, without a PR?
  
  I have seen [Trunk Based Development - release branch testing](https://devops.stackexchange.com/q/9855/30208) but it did not fully answer my question. Thanks in advance for your patience with a n00b question :D
  
  **Tags:** git, automation, testing, tdd
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-05-04. Score: 2
  
  You can still use pull requests with [Trunk-Based Development](https://trunkbaseddevelopment.com/). Especially with larger teams, using [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/), you would open a pull request into the trunk, which would start the build process. Depending on your environment and desire to have rapid merges, you could merge the pull request automatically, perhaps based on things like no new style violations, sufficient code coverage, tests pass, and no new static analysis violations, and defer the human review for later.
  
  > **Comments:**
  > **username_0**: Is that still trunk based though? Your suggestion sounds like people should create feature branches rather than committing directly to main, which is our current situation.  
  > **username_1**: @username_0 Did you see what site the links point to? Yes, that's from the definition of trunk-based development.  
  > **username_0**: I did, however not committing to main is surely not pure trunk based dev https://youtu.be/ASOSEiJCyEM  
  > **username_1**: @username_0 In that video, Dave Farley is talking about human-gated pull requests. I mentioned this in my answer - you can still use pull request tools (like GitHub, Bitbucket, and perhaps others) to perform automated checks and automatically merge, while deferring human reviews for later. However, there is no way to both commit to trunk _and_ run your pipeline before a merge. You need to decide what is more important - waiting a short period of time (hopefully minutes) to get your automated results and merging or integrating faster and getting results later.  
  > **username_0**: Ah with you. I thought Dave Farley is saying that all PRs are always evil. Automated testing ftw.  
  > **username_1**: @username_0 I'd have to rewatch that video to be 100%, but I watched it when it came out (his channel is great). I highly doubt he'd object to your pipeline blocking a merge, but I suspect he's say that you should be aiming to get your branch into main (meaning it passes the pipeline) within a day or two of opening it. That also has implications for how long your pipeline should take to execute - 10 or 15 minutes could be a very long pipeline. You can always defer more to post-merge - it's all about balancing ensuring quality, reducing risk, and letting people use your changes to buildon.  
  > **username_2**: @username_0 From a purely Git perspective, this debate is kind of funny. In Git, a branch is a pointer to a commit that has a name. If the "trunk" is called `main` on the remote, and you call your local branch `main`, then it's TBD. If you rename your local branch to `my-branch` then TBD magically changes into "Feature Branch Workflow", which is also known as GitHub Flow and many other popular CI workflows.  PR's are fine, just temporarily rename (or copy) your local `main` to something else and push it out so you can use the PR tool functionality, if you want to.  
  
  ---
  
  