DEV Community: Dhruv

Actions in Github

Dhruv — Sun, 27 Dec 2020 09:41:20 +0000

It has been a while now since Github released its much-awaited feature Github Action.

This post will cover some basics around what actually are Github Actions and how can it be used in the simplest of ways to automate some mundane tasks.

What is Github Action?

In layman's terms, Github Actions helps in automating software workflows like a PR review, Branch management, Issues tracking, PR labelling, and much more.

Now what is workflow?

Workflow gives you the ability to structure your own set of steps/rules/flow to build your own automation process. It can be just one workflow or multiple ones clubbed together.

For this particular article we will be looking into how can we leverage Github Action to automate the task of PR labelling. I'm very sure anyone who is reading this would've had a difficulty in remembering to label your PR according to the changes done and more often your manager/lead would drop in a comment to remind you about the same.

The good thing is now you can leave that to the Github actions bot. Let's see how.

First of all, make sure you have created all the necessary labels you want to use for your projects in Github. To do so, navigate to your project repository and click on the pull requests tab.

Click on "Labels" right next to the filter search bar which will straight away take you to the list of labels available from where you can also create new labels as per your requirements.

Now, Create a .github folder in the root of your project if not already created. This will be the directory where all your future workflow files, as well as some useful YML files, stay.
Withing .github folder create a file with ${your-file-name}.yml (I have named it assing-label.yml). Replace your-file-name with whatever you'll like to have and paste the below code in there.

Components:
- any: ['src/components/**/*']

actions:
- any: ['.github/**/*']

The above code is just a yml file that will be used by our workflow to decide which filter should be applied based on any changes.

any and all are two fields defined to match and check for files changed in the paths mentioned against the fields in array respectively.

It basically translates to this:-

If there are ANY changes in the components folder present in the src folder apply the `Components` tag to that PR.

Similarly, if there are ANY changes in the `.github` folder apply the `actions` tag to that PR.

Understand Globs Better

Okay, So far so good.

Now, we will create a workflow that will actually bring everything to life when a PR is actually created.

Jump to the Actions tab and scroll down till you see this.

Out of the options available, click on the Setup this workflow button of the Labeler Card and soon you'll see a code editor screen with some pre-populated code snippet in it.

You can choose to change the file name which is auto-generated as label.yml. Github will automatically create a workflow folder within the .github folder that we created for our assign-label.yml file.

Paste this simple code snippet in the editor.


# This workflow will triage pull requests and apply a label based on the
# paths that are modified in the pull request.
#
# To use this workflow, you will need to set up a .github/labeler.yml
# file with configuration.  For more information, see:
# https://github.com/actions/labeler

name: Labeler
on: [pull_request]

jobs:
  triage:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/labeler@master
      with:
        repo-token: "${{ secrets.GITHUB_TOKEN }}"
        configuration-path: .github/assign-label.yml # Replace this with your ${your-file-name}.yml that we created earlier.

Let's first understand what the heck is going on in this file.

name: This is just a string which is normally the name of the workflow file.

on: This one is rather the most important one. on basically tells the action to listen to a particular event which in our case is a pull_request. It will listen to any and every change on a pull_request and run this particular action every time something is pushed or changed.

More about events in Github actions

jobs will run your particular job that is triage on the latest ubuntu machine and start completing the steps mentioned. uses will download the external dependency that is actions/label@master and will run the same code with the configuration we wrote in the assign-label.yml file.

A lot of stuff happened, right!? But hang on in there. Once this is done, commit the file either to master directly or create a new Pull Request for the same.

On creating a pull request you'll see Github action in action literally.

You'll notice some new comments saying "Github actions bot added some Tag" and a green tick to signify that your checks ran successfully. In case it fails you'll see a red cross there and luckily you also have access to logs for your actions to debug them in case you need to which I'm sure in the beginning you'll have to. That's how we all learn, right !?

To see logs and the history of actions that were executed earlier you can straight away go to the Actions tab within your repo.

So, if you manage to follow the article successfully you'd have successfully automated your Pull Request labelling process, and even if you get stuck on any of the steps feel free to drop down the errors in the comment section. I'll be happy to help as much as I can.

This is just a very small use case of what Github Actions can do. You might have some other way of doing the same thing too. Feel free to let me know how do you automate your day to day workflows in Github.

If you want to discuss more on this feel free to DM me on Twitter.

Engineer vs Developer

Dhruv — Sat, 03 Oct 2020 09:35:40 +0000

It's weekend again and it calls for new food for thought kind of a topic.

What do you mean by the term "Developer" ?

This is a question that can be answered in a lot of different ways depending on the different viewpoints. According to me if you have a good logical capability and you know what tool to use when and for what use case, that makes a good Developer. I won't bring SYNTAX in between here because it can be easily googled, right?

What do you mean by the term "Engineer" ?

An engineer is someone who builds stuff. Building anything requires a lot more knowledge than just programming and logical thinking. One needs to dive into the idea/abstract of the product/tech they are working on in order to know what shortcomings are present currently in product/tech and what solutions might help solve those issues.

This debate of engineer vs developer can be a long one but one must keep in mind that being an engineer is "holistic development of developer". An all-around development of a developer makes them an Engineer. Being an engineer is more than just coding, it's also about understanding the product, how you perceive a problem statement, and start thinking of a possible solution to it.

There's a very clear and visible line between a developer and an engineer, to say the least, but this is again my opinion and it can be different for different people based on their experience.

Tell me what do you think about this comparison of a Developer vs Engineer.

Twitter - punnyhooman

Lessons learned in a year as a software engineer

Dhruv — Sat, 26 Sep 2020 13:50:13 +0000

1st July 2020 marked the completion of my one year in the tech industry as a full-time front-end engineer. I wanted to write this article on that very day, but not everything happens as you plan, right? Better late than never they say.

Don't just do, market your work

I won't be wrong if I say if you don't learn this early in your career chances are your growth might get slowed down or in the worst case, you won't climb that ladder of positions in your organization. It's very important to have this skill to present your work in such a way that the other person understands it all even if they don't have the technical knowledge required to understand your work. One thing that I have noted while working in teams is that every single person on the team is a great engineer (no doubts there!!!) but, they lack presentation skills and hence sometimes their work goes unappreciated because they couldn't explain what they did in laymen terms.

Learn to shout about your work, that will get you your promotion/bonus/appreciation

Ask for help when needed

Juniors out there, you might be able to relate to this more than anyone else. Don't feel ashamed in asking for help when you need it, your teammates understand that you are new to this whole new world and you need a helping hand. It is also important to draw a line in between asking for help and being dependent on that help. Whenever you ask for help just tell the senior folk to point you in the correct direction and try and take it from there but never depend on them to write your code/logic for you because that is not going to help you trust me. So yes don't hesitate in asking for help and senior folks please don't be arrogant and just help juniors because you've been there in that situation.

With time programming gets easier

Well, this is a very controversial statement to make probably, but in my honest opinion programming gets easier as time passes by because after some time it just comes naturally to you. Yes, I agree there are some days when you wanna bang your laptop on that wall you've been staring at for a solution of a nasty bug but apart from those days, it will get pretty smooth. But, please don't bang your laptop instead take a pillow and beat the hell out of it. You'll thank me later for this advice.

Mingle with the community

The Tech community is the most welcoming community by far and the majority of folks working in tech are so very generous and helpful to everyone that no one feels alone out there.

There are conferences going around everywhere in the world about the tools modern tech industries are using to build some exciting products, you'll also find folks making some really cool side projects and much more. Make sure to get some time out of your busy schedule and lookup for a small Meet-up happening in your neighborhood or some online tech conference because those are the places you are very much likely to meet some really cool people and who knows they might help you get your next dream job. Isn't that cool? All you have to do is meet people.

That's it for this time, I promise to make this series of article an annual thing to do if people out there find it interesting and learn from it.

If you wanna discuss tech or Breaking Bad or just say hi...

Twitter - punnyhooman