update

content/13-Experiments-With-GitHub-Actions-Merge-Group/1-Broken-Codebase-With-Conflict-Free-Code-Changes!/_index.md

@@ -194,4 +194,4 @@ Oops! The *main* branch is now broken. If you run the test, you will find that t
 
 Running CI triggered by pull requests is a fantastic way to catch this kind of bug before they reach the *main* branch (as you will see in the upcoming experimental subsections). However, there is a case where CI might not catch the bug, potentially leading to a broken codebase.
 
-Next, let’s run a series of different experiments to simulate the scenario described in this section and understand why you might need a merge group (or merge queue). After that, while simulating this feature at scale can be challenging, you will conduct a simplified experiment with it and then proceed to just enable the merge group for AWSome Books.
+Next, let’s run a series of different experiments to simulate the scenario described in this section and understand why you might need a *merge group* (or *merge queue*). After that, while simulating this feature at scale can be challenging, you will conduct a simplified experiment with it and then proceed to just enable the *merge group* for AWSome Books.

content/13-Experiments-With-GitHub-Actions-Merge-Group/2-Prepare-Source-Code/_index.md

@@ -65,7 +65,7 @@ jobs:
         run: python test.py
 ```
 
-In general, this workflow is triggered when a pull request is created or when a branch is part of a merge group (*main* branch). It sets up a CI job on an Ubuntu machine, checks out the code, installs Python 3.9, prints the contents of two files (*main.py* and *test.py*) for troubleshooting, and finally runs the test file (*test.py*) to validate the code changes. The sleep 10 step appears to add a delay, possibly for debugging purposes.
+In general, this workflow is triggered when a pull request is created or when a branch is part of a *merge group* (*main* branch). It sets up a CI job on an Ubuntu machine, checks out the code, installs Python 3.9, prints the contents of two files (*main.py* and *test.py*) for troubleshooting, and finally runs the test file (*test.py*) to validate the code changes. The sleep 10 step appears to add a delay, possibly for debugging purposes.
 
 **4.** Change the directory name to `experiment-n` where *n* is the experimental subsection you are working on.
 

content/13-Experiments-With-GitHub-Actions-Merge-Group/6-Experiment-4/_index.md

@@ -16,7 +16,7 @@ It offers the same benefits as the **Require branches to be up to date before me
 
 This feature is especially valuable for branches receiving a high volume of pull requests daily from multiple contributors.
 
-Once a pull request passes all necessary branch protection checks, a user with write access can add it to the queue. The merge queue then ensures that the pull request's changes pass all required status checks against the latest version of the target branch and any other pull requests already in the queue.
+Once a pull request passes all necessary branch protection checks, a user with write access can add it to the queue. The *merge queue* then ensures that the pull request's changes pass all required status checks against the latest version of the target branch and any other pull requests already in the queue.
 
 **1.** On the remote repository,
 
@@ -121,7 +121,7 @@ git push --set-upstream origin person-b
 
 ![00013](/images/13/6/00010.svg?featherlight=false&width=100pc)
 
- **19.** The person *a*'s pull request now should be added to the merge queue. Click **merge queue** to view the queue.
+ **19.** The person *a*'s pull request now should be added to the *merge queue*. Click **merge queue** to view the queue.
 
 ![00014](/images/13/6/00011.svg?featherlight=false&width=100pc)
 
@@ -137,7 +137,7 @@ git push --set-upstream origin person-b
 
 ![00017](/images/13/6/00014.svg?featherlight=false&width=100pc)
 
-**23.** The person *b*'s pull request now should be added to the merge queue. Click **merge queue** to view the queue.
+**23.** The person *b*'s pull request now should be added to the *merge queue*. Click **merge queue** to view the queue.
 
 ![00018](/images/13/6/00015.svg?featherlight=false&width=100pc)
 
@@ -163,12 +163,12 @@ Wait for all pull request merges to complete and be fully dequeued, then move to
 
 ![00023](/images/13/6/00020.svg?featherlight=false&width=100pc)
 
-**29.** As expected with how the merge queue operates, under the **Show main.py content** dropdown, you might notice that person *b*'s pull request includes both person *a*'s changes and the current state of the *main* branch in additon to person *b*'s code changes. As a result, person *b*'s pull request is expected to fail and will be rejected from merging into the *main* branch.
+**29.** As expected with how the *merge queue* operates, under the **Show main.py content** dropdown, you might notice that person *b*'s pull request includes both person *a*'s changes and the current state of the *main* branch in additon to person *b*'s code changes. As a result, person *b*'s pull request is expected to fail and will be rejected from merging into the *main* branch.
 
 ![00024](/images/13/6/00021.svg?featherlight=false&width=100pc)
 
-In the previous experiment, the **Require branches to be up to date before merging** rule would block other pull requests if one was ahead, requiring you to wait for the preceding pull requests to complete before manually merging yours into the *main* branch. In contrast, the merge queue streamlines this process by allowing multiple pull requests to enter the queue at once. It automatically integrates each pull request with those ahead of it and the latest *main* codebase. While there may still be cases where your pull request has not passed CI checks and requires correction, if it does pass, your code changes can be merged into the *main* branch automatically — eliminating the need to wait for preceding pull requests to be processed and merging your pull request manually.
+In the previous experiment, the **Require branches to be up to date before merging** rule would block other pull requests if one was ahead, requiring you to wait for the preceding pull requests to complete before manually merging yours into the *main* branch. In contrast, the *merge queue* streamlines this process by allowing multiple pull requests to enter the queue at once. It automatically integrates each pull request with those ahead of it and the latest *main* codebase. While there may still be cases where your pull request has not passed CI checks and requires correction, if it does pass, your code changes can be merged into the *main* branch automatically — eliminating the need to wait for preceding pull requests to be processed and merging your pull request manually.
 
-While GitHub lets you activate both the **Require branches to be up to date before merging** rule and the merge queue, using both can be redundant. The merge queue effectively manages all pull requests simultaneously, automatically integrating each one with changes from preceding requests. This removes the need to wait for earlier pull requests to complete, making the merging process smoother and more efficient. In other words, once your code review is approved, you simply add your pull request to the queue and let it handle the rest. If your pull request fails, you can correct it without any further delays.
+While GitHub lets you activate both the **Require branches to be up to date before merging** rule and the merge queue, using both can be redundant. The *merge queue* effectively manages all pull requests simultaneously, automatically integrating each one with changes from preceding requests. This removes the need to wait for earlier pull requests to complete, making the merging process smoother and more efficient. In other words, once your code review is approved, you simply add your pull request to the queue and let it handle the rest. If your pull request fails, you can correct it without any further delays.
 
-To boost commit rates and speed up merging code changes back into the *main* branch, the AWSome Books project might want to try a merge queue. Next, you simply activate the merge queue, and let it streamline and accelerate your merging process!
+To boost commit rates and speed up merging code changes back into the *main* branch, the AWSome Books project might want to try a *merge queue*. Next, you simply activate the *merge queue*, and let it streamline and accelerate your merging process!

content/13-Experiments-With-GitHub-Actions-Merge-Group/_index.md

@@ -6,7 +6,7 @@ chapter : false
 pre : " <b> 13. </b> "
 ---
 
-In the upcoming sections, you start to discover a scenario where your *main* codebase might be disrupted due to unexpected issues from conflict-free code changes. You then run several experiments on different codebases, exploring why you might opt to use the merge group. Once those tests are complete, you are going to conduct a final experiment to demonstrate the core functionality of the merge group. Afterward, you can simply enable it for the AWSome Books project.
+In the upcoming sections, you start to discover a scenario where your *main* codebase might be disrupted due to unexpected issues from conflict-free code changes. You then run several experiments on different codebases, exploring why you might opt to use the *merge group*. Once those tests are complete, you are going to conduct a final experiment to demonstrate the core functionality of the *merge group*. Afterward, you can simply enable it for the AWSome Books project.
 
 #### Content
 

content/14-Experiments-With-GitHub-Actions-Concurrency-Group/1-You-Might-Want-A-Single-Workflow-Execution-At-A-Time!/_index.md

@@ -38,8 +38,8 @@ Allowing multiple pipeline executions simultaneously can lead to several potenti
 
 GitHub Actions also provides the flexibility to control concurrency with [concurrency group](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/control-the-concurrency-of-workflows-and-jobs), ensuring that only one workflow run, job, or step is executed at a time in specific contexts. This feature can be crucial for managing resources efficiently, avoiding conflicts, and preventing unexpected overuse of Actions minutes and storage when running multiple workflows simultaneously.
 
-Therefore, with concurrency group,
+Therefore, with *concurrency group*,
 
-- **Continuous Deployment to Production Environment** can be streamlined by utilizing a concurrency group, which ensures that only one deployment is active at any given time for a specific environment. If a new commit is pushed, the current deployment can be canceled, allowing only the latest version to be deployed seamlessly.
+- **Continuous Deployment to Production Environment** can be streamlined by utilizing a *concurrency group*, which ensures that only one deployment is active at any given time for a specific environment. If a new commit is pushed, the current deployment can be canceled, allowing only the latest version to be deployed seamlessly.
 
-- **Running Tests on Feature Branches** can be enhanced with a concurrency group, which automatically cancels any ongoing tests when a new commit is pushed to the same branch. This ensures that only the most recent changes are evaluated.
+- **Running Tests on Feature Branches** can be enhanced with a *concurrency group*, which automatically cancels any ongoing tests when a new commit is pushed to the same branch. This ensures that only the most recent changes are evaluated.

content/14-Experiments-With-GitHub-Actions-Concurrency-Group/_index.md

@@ -6,7 +6,7 @@ chapter : false
 pre : " <b> 14. </b> "
 ---
 
-Let's conduct a series of experiments, independent of the AWSome Books project, to explore how implementing concurrency groups can significantly enhance CI/CD pipeline efficiency.
+Let's conduct a series of experiments, independent of the AWSome Books project, to explore how implementing *concurrency group*s can significantly enhance CI/CD pipeline efficiency.
 
 #### Content
 

content/4-Preparation/2-Create-Slack-Channels/_index.md

@@ -81,7 +81,7 @@ Click **Skip Step**.
 
 **12.** Do the same from step **8** to **11** to create the following private channels
 - `gha-ci` for CI notifications from GitHub Actions, 
-- `gha-merge-group` for merge group notifications from GitHub Actions, 
+- `gha-merge-group` for *merge group* notifications from GitHub Actions, 
 - `gha-release` for release notifications from GitHub Actions, and 
 - `gha-rollback` for rollback notifications from GitHub Actions