Your Second CI Workflow Execution

Now, try creating a failed CI workflow execution from a pull request and merging it into the main branch. You may notice that your CI workflow execution restores the cache from the main branch for its dependencies which might help speed up the CI jobs. Additionally, GitHub will allow you to merge a pull request with failed workflow execution into the main branch if no protection rules are in place.

1. Make sure you are still in the right project folder.

cd path/to/awsome-books

2. In your local repository, checkout to the main branch.

git checkout main

3. Your local main branch should now contain only the README.md file. Use the following command to pull the latest codebase from the remote main branch.

git pull

4. Create and switch to another branch named failed-job.

git checkout -b failed-job

5. Now, simulate a failed job in your CI workflow. In your .github/workflows/ci.yml file, add a step to the build-image job that could cause the workflow to fail.

1
2
3
4
5
6
7
8

  build-image:
    name: Build image
    runs-on: ubuntu-latest
    steps:
+     - run: exit 1      

      - name: Checkout
        uses: actions/checkout@v4

6. Additionally, add the --offline option to the Run unit tests and Run integration tests steps in the unit-test and integration-test jobs, respectively.

Gradle’s offline mode to build projects without accessing remote repositories or resources. When you run Gradle with the –offline flag, it will only use dependencies and resources that are already cached locally, avoiding any network activity and thus accelerating the command execution time.

• For step Run unit tests in unit-test job.

1
2
3
4
5

- name: Run unit tests
  run: |
    chmod +x gradlew    
-   ./gradlew test
+   ./gradlew test --offline

• For step Run integration tests in integration-test job.

1
2
3
4
5

- name: Run integration tests
  run: |
    chmod +x gradlew    
-   ./gradlew integrationTest
+   ./gradlew integrationTest --offline

7. Make a commit and then push to the remote failed-job branch.

git add . && git commit -m "add a failed job" && git push --set-upstream origin failed-job

8. Go to the AWSome Books remote repository. Click Compare & pull request.

9. Click Create pull request.

10. Click the Actions tab and select the workflow that is currently running.

11. Wait for the workflow to complete, and you will see that it has failed because the Build image job encountered an error, and thus the Scan image job did not run. However, you might notice that the Run unit tests, Run integration tests, and Scan source code jobs have each reduced their execution time by about 10 seconds compared to those at step 8 in 11.8 Your First CI Workflow Execution.

Let’s dive into several jobs to gain a deeper understanding of your CI workflow execution.

12. Let’s check the Build image job first.

13. You notice that the Build image job has failed due to the exit 1 command specified in step 5, which prevented it from executing the subsequent core steps.

14. Return to your CI workflow diagram and click on the Run unit tests job to view the job in details.

15. Click the Cache dependencies step dropdown. You might notice that Cache restored successfully and Cache restored from key with the key is the same as step 10 in 11.9 Update Dependency Cache.

The cache key for the refs/pull/1/merge pull request, however, is also identical. To determine which cache was utilized, check the last used attribute. The last used attribute for main should be more recent than that of refs/pull/1/merge.

16. Expand the Post Cache dependencies step dropdown, and you will see the messages Cache hit occurred on the primary key and not saving cache. This means a cache hit was detected, so no new cache is saved. You can verify this by checking the second figure in step 15, where you will see no new cache entries saved.

17. Under your remote repository,

• Select Pull requests tab.
• Choose your opened request Failed job.

18. Click Merge pull request.

19. Click Confirm merge.

20. Click Delete branch.

21. Boom!!! A problematic commit has just made its way into your main codebase. While this is just a simulation of a failed job, in real-world situations, GitHub without proper branch protection settings could let these bad code changes slip into your main codebase.

You can check the .github/workflows/ci.yml file in the remote main branch to see the step running exit 1 in the build-image job.

22. Click on the Actions tab, and you notice that the Update dependency cache workflow has been triggered. Click the running workflow to see more in details.

23. Wait for the pipeline execution to complete, and you may notice that the execution time has decreased by around 20 seconds compared to step 6 in 11.9 Update Dependency Cache. Click the job to see more in details.

24. Expand the Cache dependencies step dropdown, and you will see the message Cache found and can be restored from key and thus the Update cache job did not run. That indicates your job did restore the cache from the previous Update dependency cache workflow execution with a appropriate cache key.

25. Next, expand the Post Cache dependencies step dropdown. You will see the messages Cache hit occurred on the primary key and not saving cache. This indicates a cache hit, so no new cache needs to be saved.

26. In the GitHub Actions Cache, you will notice there is no new cache entry. In addition, the cache from the main branch is being used, as indicated by the last used attribute when compared to refs/pull/1/merge.