You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: learn-pr/github/github-actions-ci/includes/2-github-actions-workflows-ci.md
+6-28Lines changed: 6 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -157,7 +157,7 @@ You can identify the trigger event in several ways :
157
157
- If you're inspecting workflow runs programmatically (e.g., via the API), the run object includes an event property that specifies the trigger.
158
158
- You can also find the commit SHA, actor, and timestamp to trace what caused the trigger.
159
159
160
-
### Inferring the trigger from repository effects
160
+
### Infer the trigger from repository effects
161
161
162
162
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:
163
163
@@ -180,8 +180,9 @@ To identify what triggered a workflow:
180
180
181
181
These practices help with debugging, auditing, and improving workflow reliability across your development and deployment pipelines.
182
182
## 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:
185
186
1 . Identify the trigger (on:)
186
187
This section tells you when the workflow is initiated. For example:
187
188
```yml
@@ -307,15 +308,13 @@ You'll see a link named CI Workflow in the list.
307
308
| **Expand steps** | View detailed logs |
308
309
| **Download logs** | For offline or team troubleshooting |
309
310
310
-
311
-
<!-- InfoMagnus END -->
312
-
313
311
## Action logs for the build
314
312
315
313
When a workflow runs, it produces a log that includes the details of what happened and any errors or test failures.
316
314
317
315
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":::
319
318
320
319
## Customize workflow templates
321
320
@@ -410,13 +409,6 @@ steps:
410
409
411
410
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.
412
411
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
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
438
430
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.
439
431
440
432
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
0 commit comments