Skip to content

Commit 09b41b0

Browse files
authored
Update 2-github-actions-workflows-ci.md
1 parent d9a6a2d commit 09b41b0

File tree

1 file changed

+6
-28
lines changed

1 file changed

+6
-28
lines changed

learn-pr/github/github-actions-ci/includes/2-github-actions-workflows-ci.md

Lines changed: 6 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -157,7 +157,7 @@ You can identify the trigger event in several ways :
157157
- If you're inspecting workflow runs programmatically (e.g., via the API), the run object includes an event property that specifies the trigger.
158158
- You can also find the commit SHA, actor, and timestamp to trace what caused the trigger.
159159

160-
### Inferring the trigger from repository effects
160+
### Infer the trigger from repository effects
161161

162162
Sometimes you may not have direct access to the workflow run but want to infer what triggered it based on repository activity. Here's how:
163163

@@ -180,8 +180,9 @@ To identify what triggered a workflow:
180180

181181
These practices help with debugging, auditing, and improving workflow reliability across your development and deployment pipelines.
182182
## Describe a workflow's effects from reading its configuration file
183-
To describe a workflow's effects from reading its configuration file, you need to analyze the structure and contents of the .yml file stored in .github/workflows/. This file outlines when the workflow runs, what it does, and how it behaves under different conditions.
184-
### How to interpret a workflow's effects:
183+
To describe a workflow's effects from reading its configuration file, you need to analyze the structure and contents of the ".yml" file stored in .github/workflows/. This file outlines when the workflow runs, what it does, and how it behaves under different conditions.
184+
185+
### Interpret a workflow's effects:
185186
1 . Identify the trigger (on:)
186187
This section tells you when the workflow is initiated. For example:
187188
```yml
@@ -307,15 +308,13 @@ You'll see a link named CI Workflow in the list.
307308
| **Expand steps** | View detailed logs |
308309
| **Download logs** | For offline or team troubleshooting |
309310

310-
311-
<!-- InfoMagnus END -->
312-
313311
## Action logs for the build
314312

315313
When a workflow runs, it produces a log that includes the details of what happened and any errors or test failures.
316314

317315
If there's an error or if a test fails, you see a red rather than a green check mark in the logs. You can examine the details of the error or failure to investigate what happened.
318-
:::image type="content" source="../media/2-log-details.png" alt-text=" GitHub Actions log with details on a failed test." border="true":::
316+
317+
:::image type="content" source="../media/2-log-details.png" alt-text="Screenshot of GitHub Actions log with details on a failed test." border="true":::
319318

320319
## Customize workflow templates
321320

@@ -410,13 +409,6 @@ steps:
410409

411410
For more information about using artifacts in workflows, see [Storing workflow data as artifacts](https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/storing-workflow-data-as-artifacts) in the GitHub documentation.
412411

413-
<!-- INFOMAGNUS UPDATES for sub OD 1.6.4 go here. Source Material: Infomagnus team to find source material and cite sources when they update material
414-
https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/monitoring-workflows/adding-a-workflow-status-badge -->
415-
416-
## Add a workflow status badge
417-
418-
<!-- InfoMagnus END -->
419-
420412
## Automate reviews in GitHub using workflows
421413

422414
So far, we described starting the workflow with GitHub events such as *push* or *pull-request*. We could also run a workflow on a schedule, or on some event outside of GitHub.
@@ -438,17 +430,3 @@ Another action we could take is to add a label to the pull request. In this case
438430
Notice the block called `env:`. This block is where you set the environment variables for this action. For example, you can set the number of approvers needed. Here, it's one. The `secrets.GITHUB_TOKEN` authentication variable is required because the action must make changes to your repository by adding a label. Finally, you supply the name of the label to add.
439431

440432
Adding a label could be an event that starts another workflow, such as a merge. We cover this event in the next module on continuous delivery with GitHub Actions.
441-
442-
<!-- INFOMAGNUS UPDATES for sub OD 2.2.2 go here. Source Material: Infomagnus team to find source material and cite sources when they update material -->
443-
444-
## Contrast disabling and deleting of workflows
445-
446-
<!-- INFOMAGNUS UPDATES for sub OD 1.3.1 ,1.3.2, and 1.4.1 go here. Source Material: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository -->
447-
448-
## Configure Actions and workflow permissions
449-
450-
## Setup Secrets and variables for actions
451-
452-
## Use encrypted secrets to store sensitive information
453-
454-
<!-- InfoMagnus END -->

0 commit comments

Comments
 (0)