Triggering a workflow

Till now, we have used push commits to trigger our workflows. But we can do that with various more options.

For example, rather than push we could use cronjobs to run this workflow every minute

Note: I am using the variable-secrets.yaml file used in Part-1

Then we have to wait for a minute and it will work.

again, our workflow does not have any button to manually start it.

We can add that option if we use workflow-dispatch

Just make this change and push it.

Now, we can start a workflow manually from this button

Concurrency

Assume that, in the deploy job, we have told it to wait for 10 minutes (sleep for 600 seconds)

Now if the workflow starts, it will take almost 10-12 minutes to complete it. Assume that, in the meantime, someone from your team, runs a new workflow which again works with the deploy job.

Note: In this workflow, we have 2 jobs. One is docker, one is deploy.

So, it’s a bad practice. No one should allow same job to be run at the time same time.

To solve this issue, we can add concurrency to this deploy job.

Here, we have added cancel-in-progress as true to cancel any new workflow which runs the same deploy job. Also, we have group it to production-deployment.

We have manually started the workflow

Now, if we manually start another workflow, let’s wait and see it getting stopped.

You can see the latest workflow was successful but the old one was stopped as deploy job didn’t allow other existing jobs to continue.

Timeout option

Assume you mistakenly wrote 6000s (10hours) to run the deploy job. GitHub will automatically stop this after 6 hours. To prevent these, we can add timeout-minutes. Here, we want this workflow to timeout (stop) after the deploy job runs for more than 1 minute.

Once we push the commit and manually start the workflow,

As the deploy job ran more than 1 minute, it stopped

Using matrix strategy

Assume that you want to run 2 jobs; one runs on ubuntu and another on windows.

Once pushed, the workflow runs

So, 2 jobs did run successfully on 2 different devices (ubuntu and windows)

What if , we didn’t have to create 2 jobs to run same hello-world in 2 different devices? What if we could create a strategy and define which images to run and which devices to run on?

Here in this example, we want to run 6 jobs (Each image in each different OS)

Let’s push it!

Here, the job failed because alpine image does not work on windows.

The issue occurred as we didn’t though which image runs on which os. In production level, we should keep that on mind .

Let’s remove the alpine image from the workflow and push it.

Now, we have just 3 jobs as we are not running the alpine image on the 3 os mentioned

No, 3 jobs did run properly but the ubuntu-20.04 has retired. Thus it was cancelled

Let’s make changes to the ubuntu version,

This time, the jobs ran properly

Exclude, include, fail-fast, max-parrallel

What if we want to run the alpine image on ubuntu devices?

Let’s do that using exclude, include

Here, alpine will run only on ubuntu-latest and ubuntu-24.04 version.

So, in total 5 jobs.

What if we want a specific version of alpine to run on ubuntu-24.04

Let’s also set fail-fast as false to stop failing once any job fails. Also, now we have 6 jobs (lastly added the amd64/alpine image). These jobs are going to run in parallel in different devices.

Let’s set it to 2 so that, only 2 jobs run on the same time. Once the job is done, then next 2 runs.

Once pushed, you can see jobs are running 2 at a time

So, 6 of our jobs were successful

Context information

Contexts are a way to access information about workflow runs, variables, runner environments, jobs, and steps. Each context is an object that contains properties, which can be strings or other objects.

Contexts, objects, and properties will vary significantly under different workflow run conditions.

Check out this page

Let’s create a yaml file called context_testing.yaml

Let’s push the commit.

The workflow ran properly and you can verify the output here

For example, we used ubuntu-latest runner and therefore the os shows Linux here

Also in the Part-1 blog, we did create DOCKER_PASSWORD as repository secret.

Also, GitHub created a GitHub token to work with the actions.

So, we can see these outputs.

If expression

If expression is used to set rules. For example, if we want to run the docker job only on main branch, let’s modify the variable-secrets.yaml file

Let’s first create a feature/test branch

Let’s move to the branch once created

Here, we made the changes in the branch’s variable-secrets.yaml file

Let’s push it and manually trigger the workflow in the feature/test branch

You can see that the deploy job didn’t work

But why? It’s because the deploy job was supposed to be run only on the main branch.

Let’s create a pull request to add this changes to the main branch

Let’s merge the PR.

Now the if expression is available in the main branch. So, create a manual workflow in this branch

The workflow fails as the deploy job was supposed to run for 10 minutes and the timeout is set to 1 minutes. So, once it crossed 1 minutes, the job stopped.

But that’s not a big issue. If you want to run the job without error,

Move to the main branch, and then modify the sleep as 6 s

Let’s trigger the workflow in the main branch

Now the workflow became successful

GitHub Actions Certification Prep - Part 2