Dino Stančić

Learn to track releases using GitHub Actions and Google Calendar API. Simplify your workflow with our step-by-step guide.


How to Track Releases with GitHub Actions & Google Calendar

GitHub Actions is a powerful automation tool integrated into GitHub that allows developers to create custom workflows.

It uses the simple YAML syntax to define tasks that can be triggered by events such as pushes, pull requests, or schedule-based triggers.

Common use cases include:

 * Continuous integration (CI)
 * Continuous deployment (CD)
 * Automated testing
 * Managing dependencies

You can find all the information on GitHub Actions on their website.

But for now, let’s dive into this article and master the basics of GitHub Actions!


Where to find GitHub Actions?

You can find most of the GitHub actions on their official marketplace.

My rule of thumb is — before trying to integrate any action into your workflow, first check the marketplace if someone has potentially created this action.

It’s pretty common that someone has already had the same issue and decided to create and publish a GitHub Action for that issue.

And if one action doesn’t do the trick, you can always mix in more than one action to create your desired workflow.


Why did we have to create our own GitHub action?

We’re working on a project where we go through a ton of releases to our test environments (development and acceptance mostly). And it’s not the first time that we had more than one release to production in a single day.

The thing is — it started to become a bit difficult for us to track only the production releases only.

If our project managers asked us what was in the latest production release, we’d have to dig a bit to get our latest release notes.

The decision was made — we will track our production releases on the Google Calendar. This way, we’ll know when and what did we release.

”Of course, someone has already created the action for our case.”

- Dino, June 2024

No one did.


How did we create our own GitHub action?

Creating a GitHub Action is pretty straightforward, it’s well-documented and you can find the complete instructions on GitHub’s official website.

And since we’re working mostly with Typescript, this was my main weapon of choice.

The main idea was to connect the action with the Google Calendar API, so that when we call the action, we pass it some props — title and description. This would create our Google Calendar event with the passed props, completing my mission.

To connect the action with the Google Calendar API, you’ll need to do a quick setup first.

Here’s how to do it.


How to set up everything you need for this action to work?

Here’s the complete step-by-step guide on how to track your production releases on Google Calendar with GitHub Actions.


Setting up the GCP project.

First, you’ll need to create your Google Console Project (or select an existing project).

For this article, we’ll select an existing project and continue working with that.

When you’ve created and selected your project, you’ll need to create the service account that will be used for calling the Google Calendar API.

To create a service account:

 1. Open the navigation menu
 2. Go to the IAM & Admin
 3. Select Service Accounts

You can see how it looks in the image below.

When you’re in the Service Accounts dashboard click on the + CREATE SERVICE ACCOUNT button at the top of the screen.

Next, fill in the data in the first step and click on DONE. For reassurance, please check the image below.

Now, when you’ve created the service account, you’ll need to get its access keys. But first, you must create the access keys.

To create them, click on the three dots in the upper right corner and select “Manage keys”.

Also, check the image below to see what this looks like.

Next, click on the “Add Key” button and select “Create new key” from the dropdown.

When the modal pops out, select JSON and click “Create.”

After that, your browser will automatically download the JSON file with the credentials for that service account. Please check the image below for reassurance.

Now, when you’ve downloaded the JSON file containing the service account credentials — make sure you keep it open in the background. You’ll need it very soon.

The next step is to enable the Google Calendar API. You’ll have to:

 * Click on the menu
 * Select APIs & Services
 * Click on Library

Once again, please check the image below.

When in the Library, search for the “Google Calendar API” and select the first result that comes up. You’ll see something like this in the image below.

Finally — enable it by clicking the “Enable” button.

And that’s it for our Google Console Project setup! Let’s move on to the next step.


Setting up the Google Calendar.

To set up the Google Calendar, open your calendar and create a new calendar. Simply click on the + button next to the “Other calendars” title.

Please see the image below.

Now, when you’ve created a new calendar, click on the three dots next to your calendar.

You’ll need to select “Settings and Sharing”.

Next, scroll down until you find the “Share with specific people and groups” option.

Finally, click on the “+ Add people and groups” button and add the service account that you have previously created in the Google Console Project.

To find the service account email, check the downloaded JSON file. It should look something like this.

Remember when we told you to keep that JSON file open in the background? Well, now’s the time to check it.

Open the JSON file and look for the service account email.

It should look something like this code block below.

{
  "type": "xxxxxxxxxxxxxxxxx",
  "project_id": "xxxxxxxxxxxxxxxxx",
  "private_key_id": "xxxxxxxxxxxxxxxxx",
  "private_key": "xxxxxxxxxxxxxxxxx",
  "client_email": "xxxxxxxxxxxxxxxxx",
  "client_id": "xxxxxxxxxxxxxxxxx",
  "auth_uri": "xxxxxxxxxxxxxxxxx",
  "token_uri": "xxxxxxxxxxxxxxxxx",
  "auth_provider_x509_cert_url": "xxxxxxxxxxxxxxxxx",
  "client_x509_cert_url": "xxxxxxxxxxxxxxxxx",
  "universe_domain": "xxxxxxxxxxxxxxxxx"
}

For now, we’ll need just the “client_email” property.

Copy and paste it into the email input field. You’ll need to give it a “Make changes to events” permission.

Once you’ve done that, the Google Calendar part is finished. But don’t close the calendar settings yet because we need to do one more thing.

Scroll down to the “Integrate calendar” and keep the tab open.

The properties that you need for this action are:

 * client_email → from the downloaded service account JSON file
 * private_key → from the downloaded service account JSON file (just copy and paste it into the repository secrets in the format as it is in the JSON file)
 * Calendar ID → from the Google Calendar settings


How to integrate all of that with our GitHub action?

You’ve reached the final part of this tutorial. Kudos!

Now, here’s the documentation for this GitHub Action. Please check it before moving forward.

In this part, I’ll show you the most basic integration of this action.

Before we continue, a quick piece of advice. Do not use the service account credentials and Calendar ID (the one I asked you to keep open above) directly in your workflow.

Instead, add that data as Repository Secrets for your project and use them that way.

If you’re not familiar with this method, please check the documentation for using secrets in GitHub Actions.


Create a Calendar event on release

Here’s how to create a Calendar event on release — the most basic integration of this GitHub Action.

Check the code below.

name: Test Action On Release

on:
  release:
    types: [published]

jobs:
  google-calendar-event:
    name: Google Calendar Event
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        id: checkout
        uses: actions/checkout@v4

      - name: Add Google Calendar Event
        uses: stancic/create-google-calendar-event@v1.2.1
        id: create-event
        with:
          service_account_client_email:
            ${{ secrets.SERVICE_ACCOUNT_CLIENT_EMAIL }}
          service_account_client_private_key:
            ${{ secrets.SERVICE_ACCOUNT_CLIENT_PRIVATE_KEY }}
          calendar_id: ${{ secrets.GOOGLE_CALENDAR_ID }}
          summary: ${{ github.event.release.name }}
          description: ${{ github.event.release.body }}

      - name: Print Output
        id: output
        run: |
          echo "${{ steps.create-event.outputs.event_link }}"

For this action, we’ve used our repository secrets for our credentials setup and our release name (title) and release body for our event summary (title) and description.

If everything is set up correctly, a release event should be visible in your Google Calendar once the release is published.

You should see something like the image below.


Which GitHub Action is next?

GitHub Actions can do much more than just CI/CD. They are your automation sidekicks for all kinds of tasks.

By integrating it with the Google Calendar API, you’ve made tracking production releases a breeze. And it was all done so quickly.

We’d love to hear from you!

Have you tried creating custom GitHub Actions? What challenges did you face? Write to us at hello@prototyp.digital and share your latest development story.

And lastly — thank you for reading! If you found this post helpful, please share it with your network. Let’s keep this conversation going and help each other make our lives just a little bit easier.

Development

How to Track Your Production Releases with GitHub Actions and Google Calendar API

Creating API calls can make a real mess in applications, so we came up with a solution to simplify that problem. In this tutorial, you can find out how we created our solution using Axios for React applications. 

Easier API calls with a wrapper around Axios - Prototyped

Keep reading and discover how did we come up with a solution that can simplify that problem.

The most common way to create requests from the frontend application is to use Axios. As per official Axios documentation, Axios is a promise-based HTTP Client for node.js and the browser. On the server side, it uses the native node.js  http module, while on the client (browser) it uses XMLHttpRequests.

Axios is straightforward to use, but creating API calls can become messy if you repeat configuration across multiple files.

We encountered this issue in one of our projects, where API calls had become complicated and bloated our code. To address this, we created a class-based wrapper around Axios. This centralized the configuration to a single file, cleaning up our code. It also standardized how API requests are made, improving consistency.

By the end, we had developed a reusable solution that can simplify API calls for any project, regardless of framework. Keep reading to learn more about our Axios wrapper and how it streamlined API requests.


Using Axios

Using Axios in a React application is fairly easy. To use it, you just need to import it, and you’re already set.

import React, { useState, useEffect } from 'react';
import axios from "axios";

const RandomUserName: React.FC = () => {
  const [user, setUser] = useState()

	async function getRandomUser() {
	  try {
	    const data = await axios.get("/api/users/random_user");
	    setUser(data)
	  } catch(err) {
	    console.log("error: ", err);
	  }
	}

  useEffect(getRandomUser, []);

  if (!user || !user.name) return null;

  return <p>{user.name}</p>
}



As you can see in my simplified example, it’s fairly easy to use. Only, if we were to use it in a real-world application, things could get a bit more complicated.

Not in a way that it’s complicated to use Axios itself, but the way to configure it and to keep it consistent for each use. Especially in some big applications where we have an API call on every page a user visits.

import React from 'react';
import axios from "axios";
import { FormProvider, useForm } from 'react-hook-form';

const CreateRandomUserForm: React.FC = () => {
  const form = useForm<User>();
  
	async function createRandomUser(randomUser: User) {
	  try {
	    await axios.post("/api/users/random_user", randomUser, {
        baseUrl: '<https://some-base-url>',
        beforeRedirect: someBeforeRedirectFunction,
				headers: {
          'Content-Type': 'application/json',
          Authorization: `some token`,
        },
				... // you get the point
			});
	  } catch(err) {
	    console.log("error: ", err);
	  }
	}

  return (
  	<FormProvider {...form}>
		<form onSubmit={form.handleSubmit(createRandomUser)}>
			<UserFormInputs />
		</form>
	</FormProvider>
  );
}


In this “complicated” example, you can see that we’ve added a configuration. Now imagine if you have more files with API calls that need to add that type of configuration + some interceptors.

Nonetheless, our code can become bloated if configured incorrectly.

React-wise, we can create a shared hook that’s creating an instance of the Axios client and then configure it to keep it consistent for every API request. That’s something similar we’ve come up with.


Our Axios client

In one of the applications we were developing, API calls had become complicated and bloated our code due to the initial setup. We noticed this issue and wanted to refactor the code. We developed a class-based solution for making API calls that can now be reused across most projects, regardless of the framework.

This led us to create axios-http-client which is also straightforward to implement.

You simply define a shareable class, add any necessary configuration, and then you can reuse it throughout your project. For example:

// http.ts
import { HttpClient, HttpClientConstructor, HttpClientAxiosConfig } from 'axios-http-wrapper';

// Type it for autocomplete.
const httpClientConstructor: HttpClientConstructor = {
  baseUrl: '<http://some.api.url>',
}

const config: HttpClientAxiosConfig<BaseModel> = {
  headers: {
    accept: 'application/json',
  };
}

// HttpClient class can have some BaseModel passed as a generic.
export const MyHttpClient extends HttpClient<BaseModel> {
  constructor(private endpoint?: string) {
    super({
      baseUrl: '<http://some.api.url>',
      endpoint: this.endpoint,
    }, config);

    // If you need to configure some axios interceptors, you can also do this here.
    this.client.interceptors.response.use(
      (response) => response,
      (error) => error,
    );
  }
}


More examples of how to use it can be found on our GitHub repo  or our npm repo. In this documentation, you can also find a simplified way to use it in a React application as a hook.

There were two main reasons we created axios-http-client:  

 * We wanted to simplify how API requests were created in order to clean up the code and make it easier to understand.
 * We aimed to make API requests more consistent and less prone to errors by standardizing the process across the project.

Axios interceptors were left intact so if you need to have some custom logic before sending a request, or getting a response, you can customize it as you want. Also, if you have a custom error handling, you can add that logic here.


Conclusion

When setting up API calls, it's easy for the code to become messy and disorganized if the process is not properly standardized. While this may not be a major issue for small applications, it can significantly complicate development on larger projects.

Our axios-http-client aims to address this by providing a simple and reusable way to make API requests. Feel free to try it out on your next project and let us know your thoughts. If you have any other questions or run into issues, please check our GitHub repository.

I'd like to thank our CTO Vlatko Vlahek, who initially suggested developing a client to simplify API calls. Thanks also to colleague Marko Mrkonjić for demonstrating how to create a reusable hook for making requests in React applications. We appreciate the contributions that helped shape this library.

Thank you for your the time to read this blog! Feel free to share your thoughts about this topic and drop us an email at hello@prototyp.digital.

Streamlining APIs using an Axios Client

In this article, you can learn how to implement the offline status feature and see examples in applications.  

Detecting network state with Javascript - Prototyped

From time to time our devices tend to lose connection to the network due to numerous reasons. Those issues can range from our Internet service provider dropping the connection, to us being out of network reach which ultimately results in the user being offline, even for a brief moment. This could cause a very bad experience for the user if they don’t understand the network status, such as requests not showing the desired data, form submitting not doing anything, loader spinning indefinitely.


Better UX

While online or offline state detection might seem like a futile or pointless feature, we think it’s a great user experience where our user knows what’s going on with their application and in this case, what’s going on with their connection because there are certain scenarios where users could lose some of their work.

With applications like Google Docs, there’s a risk that users can’t save a document they were working on or maybe some important part of that document without their knowledge and it’s always a good idea to let the users know that there’s a risk of losing their work. So Google Docs have a nice feature to let the users know that they’ve lost their internet connection.

Spotify also does a great job of telling its users that they’ve lost their connection. Since losing an internet connection while listening to some music won’t result in losing important data like writing some document would, it would certainly contribute to some bad user experience if users don’t know what has happened and why is their music not playing. As seen from the image, Spotify shows a notification near your name with a message about what has happened.

Our application, Propoze, also has network detection. With Propoze, users can create proposals that they can save as drafts or send to the clients. Writing proposals takes a considerable amount of time and we didn’t want our users to lose their work due to network connection issues. A simple solution we came up with for this kind of problem is that we’re letting our users know that they have lost their connection and that their changes could be lost. As seen in the image below we’re showing a toast message that their settings will be saved next time they come online.



Javascript Navigator attribute

Javascript has implemented a Navigator object that can be retrieved using the window.navigator property. The Navigator object has a lot of properties implemented. Most of the properties are read-only and most are used for checking different states of the user agent. For example, we can check if a user has enabled their cookies by checking window.navigator.cookieEnabled property. We can also detect users' geolocation by checking window.navigator.geolocation property.


The property we’re checking for this use case is window.navigator.onLine. With this property, we’re detecting network changes for our user. Although navigator.onLine is compatible with all browsers, this feature behaves differently on some browsers. For Chrome, Safari, and Firefox, the offline state is detected when the browser can’t connect to a local area network or a router. In Internet Explorer switching the browser to offline mode is detected as the offline state.


If you’re using virtualization software you should pay attention to this state since there’s a risk of getting false positives because some virtualization software has virtual ethernet adapters that are always “connected”.


Network status listener

One way of detecting a network state is by checking a state of an object in the simple example below.

// returns true if online, false if offline
const online = window.navigator.onLine;

if (online) {
  console.log("Online :D");
} else {
  console.log("Offline :(");
}



The other way to go is by listening for the events on window.ononline and window.onoffline. They both fire on window.navigator.onLine state change. window.ononline returns true if the browser is online and window.onoffline returns true if the browser is offline. You can do this also by attaching an addEventListener to the window object. I found this approach to be more straightforward so I’ve been using it more.


window.addEventListener("online", () => {
  console.log("Online :D");
});

window.addEventListener("offline", () => {
  console.log("Offline :(");
});



If you need to detect the initial network state you should use window.navigator.onLine. But if you require to listen for changes in the network state, you should attach a listener as in the second example.

For this purpose, I’ve created a simple CodePen example in which I’ve implemented both examples I’ve talked about

You can play with this example and see how it works and maybe implement it in your next project.



Conclusion


There are several ways of handling users' network state that all represent a great user experience. Furthermore, a lot of top-tier applications are mitigating the connection loss so users don’t even seem to notice that their connection has been lost. At least, some of them just notify their users about connection problems.

So, if you’re implementing a feature in your application and there is a possibility of users losing their progress, such as filling in long forms, or creating and editing some data, that needs to be handled. If that’s the case, I would recommend implementing this feature of detecting their network state with the help of a Navigator object and acknowledging them that they could lose their progress. However this is implemented, it will surely give users a tiny bit of a better user experience while using your application.


Thank you for your the time to read this blog! Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital.




AuthorDino Stančić

Start a Project