Workflow event filters and activity types

We have used push and workflow_dispatch event by now but there were no action types

but for other events, we have activity type

Let’s create a file workflow-filters.yaml and add these

Here schedule is set to run the workflow in every 59th minute.

Then the branches-ignore will ignore creating workflows if any commit is pushed on feature/* (for example, feature/test) and test/* branches.

Again, while using branches, we can mention which branches to work and which not to (by using !)

Again, for PRs, if it’s open or closed, it will work

again, it will ignore README.md file PRs and work on main branch PRs only.

Let’s push this to the main branch

The workflow worked perfectly and it was triggered as the commit was pushed to the main branch which we mentioned.

Skipping Workflow run

Sometimes there are files like README.md for which you don’t want to run the whole workflow. Let’s add some comment and add one of the keywords in the commit message to escape the workflow

so, no workflow worked

Also, you can manually disable workflows from the page as well

Debug Logging

Used to debug on a bigger level.

Let’s create e debug.yaml file and add these

Here we just saved USER_1 info in USERNAME and then saved in the GITHUB_ENV. Later on a next step, we tried to look for USER_1 value and finally $USER_2 value

Let’s push it!

The workflow failed

We have got the value for USERNAME (USER_1) but failed as we added exit 1

In this way, step 4 was skipped

But if you wish to know more details of why step 4 was skipped, let’s re-run the job while enabling the debug logging

When => is true and the result is true, then only the step works. Else it fails!

You may also download the log

We may also you REST API to check our logs and error

use

curl -L -H "Accept: application/vnd.github+json" -H "Authorization: Bearer " -H "X-GitHub-Api-Version: 2022-11-28" https://api.github.com/repos/OWNER/REPO/actions/jobs/JOB_ID

Just copy paste this one to any of the editors and modify like this

Firstly, copy this link

Now modify the REST API code according to the pasted link

Then create your token if your repository is private

While creating the token, I have selected the private repo

Then modify the script and run in your command line (after installing curl)

Input options for workflow_dispatch

As we know, workflow_dispatch gives us the option to start the workflow, we can add more options to it

Let’s create this yaml called trigger-inputs.yaml

Once we commit the changes and go back to actions and choose this “Trigger workflow with Various inputs” workflow, and press Run workflow, we can see this

Let’s populate it

Got this output

Why did the second step skipped? That’s where we should use debug-logging check

It checks this one to evaluate if it should move to next step or not

Here it got Result as false because success returns a boolean true but input.run-tests has string ‘true’

So, just make this true a boolean in the yaml file.

Then push it and start a workflow

This time all of the steps were successful

Trigger events with Web hook events

There are various ways to use web hooks specially these

We have seen how workflow_dispatch can be used to take custom inputs and repository_dispatch works somewhat like that. But you need to use REST API and get some data for it.

again workflow_call gives output in a much good looking way, making it suitable to notice

Whereas wokflow_run lets one complete a workflow and then to start another one (here build-workflow.yml has to be completed before deploy-workflow.yml)

Continuous Integration (CI)

NodeJS Application Overview

It’s an open-source runtime environment that enables developers to exectue code outside of web browsers. With NodeJs, developers can use front end and back-end using JS . As it’s build on top of Chrome V8 Javascript Engine, developers can use these features now.

We use npm to run the commands. NPPM stands for Node Package Manager which is package manager for JS and Node.js applications.

package.json is mostly used to give information and dependencies about the project, then we use npm install command to install the dependencies. Once done, node_module gets created.

In index.js has the main code for the project and test.js has the test cases. We use npm test to run test.js files.

Then we start npm start to start the application.

DevOps Pipeline

Assume we have triggered a workflow when someone pushes to a feature branch. The workflow triggers the CI pipeline which looks like this

After the CI part is done, we deploy the application using CD pipeline

Once the CD part is done, the developer raises a PR to start the Continuous Delivery Process.

Once this is done, we will collect different reports and run post build

So, as a whole ; this is our pipeline.

Let’s do a DevOps Pipeline project hands-on

Import this repo in your own account

CI work

Firstly create a feature/explore branch from the main branch

Then go to the VS code version

In the workflow folder, we have a workflow created named solar-system.yaml

Firstly, the workflow name was set to Solar System CI/CD, then it would trigger manually (workflow_dispatch), push on main and feature/ branches and pull requests in the main branch.

Then we passed mongodb database values. But how did we generate them?

Firstly, I created a free database

Use this part in the variable of the workflow

We will now create the database user

Also, give the atlas admin access

Then in the repository’s setting, go for Secrets and variables and choose actions.

Then add a variable name MONGO_USER as ‘demo’

and secret as MONGO_PASS as ‘demo4894’ as we set these for a database user

Finally, push the changes

. The workflow then started in the actions

All of our check did pass

But can we access the unit test report file?

Yes, we did save that as an artifact

What if we want to run our application in different operating system?

Yes, we can do that via matrix strategy

Let’s create a yaml file which has exactly the same content as the solar-system.yaml but with these changes

The changes are done to use various nodejs versions (18,19,20) in various devices (ubuntu, macos)

Once we push the changes, we got this one

Code Coverage

Code coverage works like unit test which actually generates some report (within code-coverage folder) . We then upload them as artifact (Code-Coverage-Result)

Here this job (code-coverage) almost works same as unit-testing but code-coverage generates a report using npm run coverage. Then it uploads the file.

Once we push the code, we get this error

This is because of this threshold which should be 90% for global standard. But this is not something we are bothered now.

So, we need to solve this issue. But before that, let’s verify some basics

Here we have 3 jobs where testing job does step in ubuntu and windows. Reports jobs upload report in AWS S3 and exists, and deploy job runs on ubuntu……….

So, you can see the testing happened in 2 different devices (ubuntu, windows) and it’s important to continue testing even if one device causes error. Else the action will fail each time any device causes error

That’s why we use if and continue-on-error

It lets the action to move further if the condition is fulfilled.
For example, if we want to check if the os is ubuntu or windows,

This will look like this. Assuming that the testing job was completed properly and we had an error on reports job, deploy job will be skipped

About continue-on-error, it lets the workflow run even a step fails

For example, if we apply this to our reports job,

Now even if the reports job fail, the deploy job won’t be skipped

Status Check Functions

There are actions to check the result or success for the earlier step in github actions. We use them to move to next step.

In our code, once the threshold one failed, it skipped other steps. We don’t want that.

So, let’s use continue-on-error on this step to let other steps do their task

So, this time the workflow ran properly although the threshold error still remains

Again, we could have done that using if expression. But for that, we would have needed step contexts.

We can check other step’s output and use it in the if expression

So, in our code, we could set an id for the step Check Code Coverage. Then using that step id’s outcome, we can set the if expression

Now the step Archive Test Result will work even if the previous step gets a success or a failure. Let’s push this change.

It’s still failing

This is because of the status check value. It’s by default success().

So, it’s looking for success() only. Failure is not getting accepted.

It’s actually like this in default

So, we need to remove the default value success(). This if statement now works when the earlier step fails.

Let’s push the changes.

This time, Archive test results and other steps were successful despite the error in Check Code Coverage step

but there is an issue. If somehow the Check Code Coverage step gets success, the Archive Test Result will fail.

To solve this issue, we can set always()

If we use this, the Archive Test Result will always work no matte if the earlier step fails or passes.

So, here you can see all steps after Check Code Coverage is working despite the step failed.