As always, here is the official documentation link.

Prerequisites

The only thing required is a GitLab project containing our source code and Dockerfile.

GitLab Runners

Overview

A GitLab Runner is an open source application that executes the jobs of a pipeline. We can install this program in four different ways:

• Local server

• Docker container

• VM

• Cloud Provider

For this example we will use a Docker container, as it simplifies the whole process.

Runners can also be categorized as:

1. Shared: All project in a GitLab instance can use this Runner

2. Group: All projects in a specific group can use this Runner

3. Project: Only a specific project can use this Runner

For this example we will create a Runner that will be assigned to a specific Project.

Executors

Now that we know what Runners are, let's dive a bit deeper on how they work. An executor is the environment on which our pipeline will run. These also come in different flavors, so some examples include:

• Virtual Box

• Shell

• Docker

• Kubernetes

• ...

So for example, a Shell executor will run the pipeline directly on the host shell, a Docker executor will create a container to execute the pipeline and so on.

Yes, we will be using a Docker executor. Good guess!

Creating our CI/CD

Time to start implementing our pipeline. In order to do that we need to take a few setup steps. These include:

1. Create a ci .yml file

2. Create a Runner container

3. Register the Runner to the GitLab project

1. Starting with the ci file

In order to run a pipeline on a GitLab project we need to create a .gitlab-ci.yml file on the root of our project's source code.

Let's see an example:

variables: 
  DOCKER_TLS_CERTDIR: "/certs"

docker-build:
    image: docker:latest
    stage: build
    services:
        - docker:dind
    script:
        - echo $CI_REGISTRY_PASSWORD | docker login -u $CI_REGISTRY_USER $CI_REGISTRY --password-stdin
        - docker build -t $CI_REGISTRY_IMAGE:latest .
        - docker push $CI_REGISTRY_IMAGE:latest

Here's what's going on:

• The docker-build job uses the latest image of Docker as base image

• We name this stage build

• dind (“Docker-in-Docker”) means running Docker within a Docker container. Thus, a new Docker engine is spawned within a container, providing an isolated environment for managing containers.

• After that, we begin our script commands:

  1. We login to our repository's registry using the docker login command. Notice how we can directly pull the PASSWORD , USER and REGISTRY variables from the platform.

  2. We build our application image

  3. We push the image to the repository registry

You can find more information in the official documentation:

• Run your CI/CD jobs in Docker containers

• Use Docker to build Docker images

2. Creating our Runner container

As we previously said, we need to create a docker container that has the Runner software listening for requests. Using a docker-compose.yml file we can describe the service like so:

version: '3.8'

services:
  gitlab-runner:
    image: gitlab/gitlab-runner:alpine
    container_name: gitlab-runner
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

The only thing to notice here is how we mount the host docker.sock inside the container, in order to be utilized by the Runner service.

Then we simply docker compose up -d !

3. Register the Runner

And the final part is to register our Runner on the GitLab repository. Here's what we need to do:

Firs navigate to your GitLab project Settings > CI/CD and expand the Runners tab. Here we need to create a new project Runner configuration. Click on the New project runner button.

The configuration needed for this is:

1. Select Linux as operating system

2. Provide a Runner description

3. Check the Run untagged jobs, as we won't be using tags

After clicking the submit button, our Runner configuration is ready. The important thing to keep here is the --url parameter provided by GitLab, as well as the --token

Great, now we just need to register this configuration to our Runner container!

To do that we need to enter the container shell so that we can execute the register command. To do that type:

docker exec -it <container-name> bash

Now, inside the Runner container, we execute the following command:

gitlab-runner register -n \
  --url "URL" \
  --registration-token REGISTRATION_TOKEN \
  --executor docker \
  --description "My Docker Runner" \
  --docker-image "docker:24.0.5" \
  --docker-privileged \
  --docker-volumes "/certs/client"

Running the pipeline

That was it! 🎉

The Runner is registered and all that's left to do is run our pipeline. We can do that from the project CI/CD > Pipelines tab.

After the image gets built, it will be automatically to our GitLab container registry with the tag :latest.

Till next time! ✌️

As always, here is the official documentation link for GitHub actions.

Prerequisites

Before we start implementing our pipeline, we need to set up our container registry and GitHub repository.

Docker Hub

Our action will require access to a Docker Hub repository. The preferred method of authentication is the use of an access token. Here's what you need to do:

1. Create an account on Docker Hub
2. Create a repository with the desired name of your image
3. Click on Account settings -> Privacy, and generate a new access token.

Note: Make sure to save the token's value because it will not appear again after a page refresh.

GitHub

Select a GitHub repository where you want to implement the automated action and follow these steps:

1. Click on Settings -> Secrets -> Actions and select New repository secret.
2. Create a secret named DOCKERHUB_USERNAME and add your Docker Hub username as a value.
3. Create another one named DOCKERHUB_TOKEN and add your Docker Hub access token that you generated earlier as a value.

Creating our action

Once we have the container registry and GitHub repo set up, we can create the workflow file. To do that:

1. Go to your GitHub repository and click on the tab Actions.
2. There you will find some suggested pre-built workflows, and an option to set up a workflow yourself. Click on that.

Writting the file

Each workflow is represented by a .yml document.

Below is our Docker image build and push .yml file.

name: Docker image build and push

on:
  push:
    branches: [ "master" ]
  pull-request:

jobs:

  build-push:

    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Login to DockerHub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build and push
        uses: docker/build-push-action@v3
        with:
          context: .
          push: true
          tags: <username>/<repository>:latest

Here's what's going on:

1. name: The name of your GitHub action.
2. on: Controls when your action will run.
3. push: and pull-request: Triggers the workflow on every push request at the master branch, and every pull-request.
4. jobs: A workflow consists of one or many jobs that can run sequentially or in parallel. For this example, we only use one job named build-push
5. runs-on: The OS you want for the runner environment that executes the workflow. For this example, we will use Ubuntu as it has Docker pre-configured. Other popular options are windows-latest or macos-latest.

6. steps: Each step runs in its own process in the runner environment. Steps consist of:

   • name: Describes each step.

   • uses: Selects a pre-built action to run as part of a step in your job.

     For example here we are using the actions/checkout@v3, docker/login-action@v2 and docker/build-push-action@v3, as part of our workflow.

     You can also use any custom action from the GitHub actions marketplace.

   • with: Input parameters for this step's pre-built action.

     For example, in the second step, we pass as parameters a username: and password:. Notice how the values are drawn from the repository secrets that we set up earlier.

     In the third step, we have a context: parameter that indicates the location of our Dockerfile, a push: parameter set to true and a tags: parameter where we can define what tags we want for our Docker Hub repository.

More on GitHub actions syntax here.

Deploying the workflow

That was it! 🎉

All that's left to do is deploy our action for the first time, and we can do that by committing this file to our repository. This will save it under .github/workflows/docker-image.yml, and trigger the workflow.

After the image gets built, it will be uploaded to your Docker Hub repository with the tag :latest.

You can find the overview of each workflow under the Actions tab on your GitHub repository, as well as a detailed log of each job step.

Till next time! ✌️

In this article, we will take a look at how you can split your endpoints logic into different files by utilizing the express.Router class.

As always, here is the official documentation link for a more detailed look at Express routing.

The basic setup

Let’s suppose that our API looks like this:

const express = require('express');
const app = express();

app.get("/", (req, res) => {
  res.send('hello world');
})

app.post("/", (req,res) => {
  // User login code
  // …
})

This is the most basic setup, and it’s quite ok if you don’t plan on using too many endpoints.

But let’s suppose we want to add another path to our API. Our code would look like this:

const express = require('express');
const app = express();

// Home route - - - - - - -
app.get("/", (req, res) => {
  res.send('hello world');
})

app.post("/", (req,res) => {
  // User login code
  // …
})

// Register route - - - - - - - - - -
app.get("/register", (req, res) => {
  res.send('Register an account');
})

app.post("/register", (req,res) => {
  const user = req.body.username;
  const password = req.body.password; // Always encrypt passwords
})

Now it starts to get a bit difficult to read, hence the comments to section out the different routes.

A better technique

Luckily, we can create chainable route handlers for each path, and reduce some of the repetitive code.

We can do that by using the .route() built-in method. Here’s how that works:

const express = require('express');
const app = express();

// Home route - - -
app.route("/")
  .get((req, res) => {
    res.send('hello world');
  })
  .post((req, res) => {
    // User login code
  })

// Register route - - -
app.route("/register")
  .get((req, res) => {
    res.send('Register an account');
  })
  .post((req, res) => {
    const user = req.body.username;
    const password = req.body.password; // Always encrypt passwords
  })

Yea, that looks much better. But still, it’s not practical for a large number of endpoints, since all of our code is on the same file. You can imagine how messy that can get if we just keep adding more.

The routers solution

Let’s take a step back and look at our project’s directory tree.

At this point it’s very simple, just our app.js file:

/project-root-folder
  app.js

But in order to start using routers, it is best practice if we make a separate directory to store them. So let’s make one:

/project-root-folder
  app.js
  /routers

Great, now we can start creating our router files. Let’s make one for our "/" endpoint named homeRoute.js:

/project-root-folder
  app.js
  /routers
    homeRoute.js

const express = require('express');
const router = express.Router();

router.route("/")
  .get((req,res) => {
    res.send('hello world');
  })
  .post((req,res) => {
    // User login code
  })

module.exports = router;

Okay, so what is going on here?

A router file is a JavaScript module, a piece of code that can be imported when needed. More on modules here. For it to work, you need to require express and use the module.exports command at the end of the file.

Right, so how on earth do we use that in our app.js file? Here’s how:

const express = require('express');
const app = express();

// Import the homeRoute.js file
const homeRoute = require('./routes/homeRoute');

// Use it as an endpoint
app.use(homeRoute);

Now that’s what I’m talking about!

Let’s implement the "/register" route in the same fashion and call it a day:

/project-root-folder
  app.js
  /routers
    homeRoute.js
    registerRoute.js

const express = require('express');
const router = express.Router();

router.route("/register")
  .get((req,res) => {
    res.send('Register an account');
  })
  .post((req,res) => {
    const user = req.body.username;
    const password = req.body.password; // Always encrypt passwords
  })

module.exports = router;

And in app.js:

const express = require('express');
const app = express();

const homeRoute = require('./routes/homeRoute');
const registerRoute = require('./routes/registerRoute');

app.use(homeRoute);
app.use(registerRoute);

Conclusions

And that was it! 🎉

I hope this helped you organize your Express API as it grows bigger with more endpoints. In a future blog post, we will explore the concept of controllers, a more advanced technique for splitting your JavaScript logic.

Till next time! ✌️

For this tutorial, we will use vanilla Node.js and Express, as there really is no need for any extra middleware like Passport.js. It's a really simple process and it only requires you to follow a few basic steps.

Also, make sure to take a look at the official documentation page for a more detailed walkthrough.

The OAuth flow

Let's take a quick look at how GitHub OAuth works under the hood before we start to implement anything.

1. The user clicks on the sign-in button and gets redirected to GitHub, where he can authorize your application.
2. GitHub then redirects back to your application, providing us with a temporary code as a URL parameter (query string).
3. Your application can then exchange this temp code for an access token. This token can be used to retrieve user data.

Creating an OAuth app

First of all, we need to create a GitHub OAuth app.

Head over to your GitHub account settings, and then navigate to Developer settings at the very bottom. Select the OAuth Apps option, and then click New OAuth App.

Now you need to fill in some information, regarding your application. This will be:

1. Application name: Give your OAuth application a name.
2. Homepage URL: This is your application home page URL including the port that it is running at.
3. Application description: Pretty self-explanatory, not required for this demo.
4. Authorization callback URL: This is the most important field. This is your application server endpoint that will receive a request with the temporary code.

Sidenote: You can change all of this later, don't worry if you mistyped something.

Click the Register application button.

The last thing we need to do is to generate a client secret. Once you generate that, make sure to take note of both client secret and the client id.

Important note: Write down the client secret at the moment of generation because you will not be able to see it again after a page refresh. (You are also prompted to do so by GitHub as well).

Client side

Fire up your VS Code champ, it's coding time!

Let's set up our Sign in with GitHub button on our client side. The script below will trigger a redirect to the GitHub authorization page, where the user will give your application access.

As you can see this process requires our client id and redirect URL that we set earlier.

<button id="githubAuth">Sign in with GitHub</button>

<script>

    const clientId = "10705503950effe4aa1e"; //Your client id here
    const redirectURL = 'http://localhost:3000/api/auth/github/';
    const url = "https://github.com/login/oauth/authorize?client_id="+clientId+"&redirect_uri="+redirectURL;

    $("#githubAuth").click(function() {
        window.location.href = url;
    });

</script>

Click the button and you will see the following screen:

By clicking the green Authorize "username" button you will be redirected to the URL that we set previously, in this case: http://localhost:3000/api/auth/github/, with a query string code.

We then need to extract this information in order to proceed.

Server side

Time we build our API so that we can execute some HTTP requests.

As mentioned, a request will be sent on the /api/auth/github/ endpoint. This will also require our client id as well as our client secret.

It's good practice to store these values in a .env file, but for this example we will simply use local variables.

So let's build that:

const express = require('express');

const app = express();

const clientId = '10705503950effe4aa1e'; // Your client id
const clientSecret = 'SECRET'; // Your client secret

app.route("/api/auth/github/")
  .get((req,res) => {
      //Get the temp code from the request
      const code = req.query.code;
      console.log("[INFO] - Got the temp code: " + code);
  });

app.listen(3000);
console.log('App listening on port 3000');

Great, now that we have our temp code, we can make a POST request to https://github.com/login/oauth/access_token in order to get our access token.

For this request, we will also need our client id and client secret. To make the POST request, I'm using the node-fetch library, but it's totally up to preference.

Let's create this functionality:

// Building the request URL
const url = "https://github.com/login/oauth/access_token?client_id="+clientId+"&client_secret="+clientSecret+"&code="+code;

//Get the access token from GitHub
fetch(url, {
    method: 'POST',
    headers: { 'Accept': 'application/json' }
})
.then(res => res.json())
.then(json => {
    const token = json.access_token;
    console.log("[INFO] - Got the access token: " + token);
});

Cool, now let's use this token to receive user information.

All we have to do is another POST request to this URL: https://api.github.com/user. We also need to include the access token we just acquired as a header parameter. Here's the code block:

//Get the user data from GitHub
fetch("https://api.github.com/user", {
    headers: { 'Authorization': 'token ' + token }
})
.then(res => res.json())
.then(json => {
    const user = json.login;
    const organization = json.company;
    const email = json.email;
    const image = json.avatar_url;

    console.log("[INFO] - Got github data for user: " + json.login);
});

And that was it! 🎉 We have successfully acquired the user information we need for our application.

So to put it all together now, here's the finalized express application:

const express = require('express');
const fetch = require('node-fetch');

const app = express();

const clientId = '10705503950effe4aa1e'; // Your client id
const clientSecret = 'SECRET'; // Your client secret

app.route("/api/auth/github/")
  .get((req,res) => {
      //Get the temp code from the request
      const code = req.query.code;
      console.log("[INFO] - Got the temp code: " + code);

      // Building the request URL
      const url = "https://github.com/login/oauth/access_token?client_id="+clientId+"&client_secret="+clientSecret+"&code="+code;

      //Get the access token from GitHub
      fetch(url, {
          method: 'POST',
          headers: { 'Accept': 'application/json' }
      }).then(res => res.json())
        .then(json => {
          const token = json.access_token;
          console.log("[INFO] - Got the access token: " + token);

          //Get the user data from GitHub
          fetch("https://api.github.com/user", {
              headers: { 'Authorization': 'token ' + token }
          })
          .then(res => res.json())
          .then(json => {
              const user = json.login;
              const organization = json.company;
              const email = json.email;
              const image = json.avatar_url;

              console.log("[INFO] - Got github data for user: " + json.login);
        });
      });
  });

app.listen(3000);
console.log('App listening on port 3000');

Note: GitHub OAuth App utilizes the scope concept, something that this tutorial does not cover. Scopes determine what permissions your OAuth App has. By default, your OAuth App has access to some basic public information about the requested user.

You can find more information on scopes at the official documentation page.

Conclusions

Now you can use GitHub as a method to manage user data for your application. There are a lot more uses to the GitHub OAuth Apps that you can utilize in your future applications, but that's a story for another post ;)

Till next time! ✌️

Some background

This was actually the first time i ever attended a tech conference, something i always wanted to do since i study computer science. But many of these big-name conferences were never held in Greece, or at least i wasn’t aware of any. Not to mention that these major events had very expensive tickets. So going abroad was a big no for me. But then i started digging a little deeper, i joined some local community slack groups and there it was. The events channel. This is where it all started.

At the time i was an undergraduate student, working for a research group at my university department (but that’s a story for another time). But i also had experience in building websites using the WordPress CMS. I’ve been doing this job since my early high school years, helping out my dad as a graphic designer who got into website design. So yea, i was very familiar with the WordPress platform and terms like HTML, SEO, plugins, domain names and hosting.

Finding the event

So back to our story. Scrolling through the events channel of this slack group, i found a post about a WordCamp conference. At first i didn’t know what it was about. But after reading the description i realized that it was a community-organized event, dedicated to the WordPress platform and web technologies in general. Also held in Athens, great news!

I immediately rushed to see the ticket price and, in my surprise, it was very cheap compared to the ones organized abroad (✨including the student discount✨). That was it, my chance to attend one of these cool conferences. But i didn’t want to go alone. See now, the problem was that none of my friends were into programming / tech stuff, thus they would be terribly bored to go with me. But then i thought of my two research colleagues (the group that i mentioned earlier), and so i texted them. They were really excited about it, so i booked the tickets and we were ready to go!

The big day

Entering the conference

On the 9th of April, my friend and I are walking towards the event location. Unfortunately, one of the guys couldn’t make it due to being sick a few days before, and was still recovering. Nonetheless, we managed to get him a bag of goodies and swag, as well as his personal name tag. Stonks!

The conference took place at the Megaron Athens Concert Hall, a beautiful building that i had never visited before. There was a big hall where all the sponsors had set their banners and filled their tables with even more swag! Notebooks, pens, stickers and t-shirts, even stress balls! We knew we were in for a treat.

Attending the speeches

Of course there were two rooms for all the speeches and presentations that took place during the event. These were split in two tracks, A and B. Both tracks were executed in parallel, so we had to choose which speech to attend each time.

Overall every presentation was very constructive and had a lot to offer, not necessarily about WordPress, but rather any subject related to website-building or managing data on the web. As a junior-level developer, i had no problem following any of the subjects as they were well-organized by every speaker and not heavily detailed with technical information.

Eat o’clock

There also was a lunch break with provided food 😋, which we really appreciated and enjoyed in a nearby park under the sun. We were each given a bag with a sandwich of choice (meat or fish), balsamic vinegar salad, chocolate cake for dessert, and of course some soda drinks.

As i mentioned there is a really cool park next to the Megaro building, perfect for a picnic or a quick walk. If you ever happen to be nearby, make sure to pay a visit!

Conclusion

I had so much fun attending WordCamp this year and i am really looking forward to doing so next year as well. The WordPress community is very passionate and well organized, kudos to all of the volunteers that made it all possible! 👏

Finally, here’s a collage of me and my buddy Panos having a blast and enjoying our first tech conference! (check out karamolegkos.dev for some epic no-css stuff!)

Till next time! ✌️

All photos were taken by the official WordCamp Athens event website