CI concurrency and push triggers

[00:00 - 00:08] In our previous lesson, we added a basic setup for CI. It is under ./.github/workflows/ci.yaml.

[00:09 - 00:15] I want to do two changes here. First one is that I wanted to also run on push.

[00:16 - 00:26] So the difference between pull request and push is push will also run this job on any merge done by GitHub itself. So a merge of a pull request.

[00:27 - 00:38] It will also run the CI on branches that have not been turned into pull requests yet. The other change that I want to make is I want to set up concurrency.

[00:39 - 01:02] We can instruct GitHub that for CI workflows, if a new commit comes in before the previous CI job has completed, we can stop that job and then run only against the new commit, because in practice, we don't care about the failing status of something that has already been overwritten by another commit. We can do this by setting concurrency.

[01:03 - 01:10] And we need to do two things. First is we need to have a name for the concurrency group.

[01:11 - 01:35] So in our case what I'm going to do is "${{ github.workflow }}", so the name of this workflow, dash "${{ github.ref }}". So the concurrency group is the name of this workflow which is "CI workflow", and the ref of the execution which would be the branch name.

[01:36 - 02:02] This means that if a request comes for the CI workflow to be executed on the same branch because a new commit came in, it would fall under the same group, while if a request came for a different branch, then it would be a different group, and similarly, if it was for a different workflow, it would be a different group. You can manually just say CI in here, but I'd like to do it with a parameter, because then it's easy to copy this for other workflows that you might be writing.

[02:03 - 02:21] So our concurrency group is workflow and ref. And when we have something in progress, we can cancel it, and we can do that by setting "cancel-in-progress: true". Like this. So with these changes, let me make a branch.

[02:22 - 02:41] And my changes. And commit this as "Change CI workflow". Push this as origin/change-ci-workflow and go and create a pull request.

[02:42 - 02:46] And we can see that the workflow is still running. So we didn't break it.

[02:47 - 02:57] Sometimes that happens but we now have the same workflow executing two times. So an error that I made here was that I set the push trigger to broadly.

[02:58 - 03:21] What we're going to do instead is I'm going to say that pull requests are the only place where we care for branches that are not the main branch to run, while for pushes we want those to run only on branch Main. So with this change, I'm going to.

[03:22 - 03:39] I'm going to amend my last commit and I'm going to push with --force-with-lease. So in "git push --force" would override a commit on the remote server.

[03:40 - 03:59] But "push --force-with-lease" will stop if there was another commit on the remote server that we hadn't seen yet on our machine. It's a good habit to be using this instead of "push --force", so "git --push-force-with-lease" and we should see it run on only one time.

[04:00 - 04:06] But again, it's running two times. And I just realized because this is called branches. So push branches main like this.

[04:07 - 04:19] Again git add my changes git commit amend. And then git push --force-with-lease. So now hopefully I got everything correct.

[04:20 - 04:33] And we're going to see that it got queued only for a single execution. As expected. We can also see if we go under actions that because of our setting to cancel in-progress workflows.

[04:34 - 04:45] The previous one was canceled. If we go into it, we can see "Cancelling since a higher priority waiting request for CI workflow-refs/pull/3/merge exists".

[04:46 - 04:58] So now new commits to a branch will stop an existing CI workflow from completing. If we go back to our branch, we should see this pass in just a moment.

[04:59 - 05:14] And it does. And we can now merge it into master. We expect to see that now when this is merged to master, we do get a trigger to run on master itself as well.

[05:15 - 05:22] And we do. If we go into actions we can see. Or when I said master, I meant the main branch force of habit.

[05:23 - 05:29] But we can see that on the main branch. Now, after a merge, we do get a run of CI.

[05:30 - 05:32] And this is everything for this lesson. See you in the next one.