DEV Community: Ishmam Abir | イシュマム・アビル

CI/CD on Local Gitlab server| Setup GitLab Runner | Self-hosted GitLab

Ishmam Abir | イシュマム・アビル — Sat, 15 Nov 2025 08:43:47 +0000

Hello again! In Part 1 of Git on Localhost | Self-hosted GitLab series, we successfully installed our own self-hosted GitLab server in localhost using Docker. You may have even gone ahead, created your first project, and added a .gitlab-ci.yml file, only to see your pipeline get "stuck" with a pending status.

If not, try setting up a project from your project list:

Note: If you already setup a project and a pipeline to your local server, then skip the setup part & directly move to the next part.

⚠ Though its a part 2 article, but I mistakenly wrote 'part 3' in the Cover image! Sorry for that! 🙏🏻

first create a repository with a name Go CI Test,then add some code there from your pc:

cd project_folder
git init --initial-branch=main
git remote add origin http://localhost:8080/root/ci-test.git
git add .
git commit -m "add: test CI"
git push --set-upstream origin main

now create a file name .gitlab-ci.yml in the root folder and add some demo CI/CD code:

stages:
  - test

dummy_test_job:
  stage: test
  script:
    - echo "Running dummy test..."
    - exit 0

An Error Occured! pipeline cant run!

This is expected! We've built the "brain" (the GitLab server), but we haven't given it any "hands" to do the work. This is where the GitLab Runner comes in.

In this article, we'll install and register our own local runner—also using Docker—to pick up those pending jobs and bring our CI/CD pipelines to life.

What is a GitLab Runner and Why Do We Need One?

A GitLab Runner is a separate application that executes the CI/CD jobs specified in your GitLab projects.

On GitLab.com, your jobs run on a shared fleet of runners managed by GitLab.
On our self-hosted server, we are in a private environment. The GitLab server knows what to do (from .gitlab-ci.yml) but has no one to delegate the task to.

We must provide our own Runner. This runner will poll our GitLab server, ask "Are there any jobs for me?", and if so, execute them. We'll use the Docker executor, which means our runner will spin up a fresh, clean Docker container for every single job, providing a perfectly isolated and reproducible build environment.

Installation Process

As we did in Part 1, we will use Docker to keep our setup clean and containerized.

Caution: Before we start, make sure Docker is running on your machine along with the gitlab container.

Step 0: Create a Docker Network

To allow our gitlab container and our new gitlab-runner container to communicate with each other by name, we should create a dedicated Docker network.

First, create the network:

docker network create gitlab-network

You can verify it exists with docker network ls command.

Next, connect your existing gitlab container (from Part 1) to this network:

docker network connect gitlab-network gitlab

This allows the runner to find the server at the hostname gitlab.

Step 1: Pull the GitLab Runner Docker Image

Open your terminal and pull the latest official image for the runner:

docker pull gitlab/gitlab-runner:latest

Step 2: Start the Runner Container

Now we'll launch the runner container. This command creates a persistent volume for the runner's configuration and mounts the host's Docker socket so the runner can launch other containers.

For Linux / macOS: (This assumes you want to store the config in /code/gitlab-runner/config, similar to Part 1)

docker run -d \
    --name gitlab-runner \
    --restart always \
    --network gitlab-network \
    -v /code/gitlab-runner/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:

For Windows (using PowerShell): (This assumes you're using the D:\code\ path from Part 1)

docker run -d --name gitlab-runner --restart always --network gitlab-network -v D:\code\gitlab-runner\config:/etc/gitlab-runner -v //var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:

Command Breakdown:

--name gitlab-runner: A recognizable name for our container.
--restart always: Ensures the runner restarts if you reboot your machine.
--network gitlab-network: Connects the runner to the same network as our GitLab server.
-v /code/gitlab-runner/config:/etc/gitlab-runner: Persistent Config. This maps a folder on your host machine to the config folder inside the container. This is critical so your runner doesn't forget its registration if you update or restart the container.
-v /var/run/docker.sock:/var/run/docker.sock: The Docker Socket. This is the magic. It gives the runner permission to use your host machine's Docker daemon. This is how the runner can spin up new containers (e.g., golang:1.21 or node:18) to run your jobs. (Note for Windows: the //var/run/docker.sock path is correct).

Step 3: Register the Runner

Our runner container is running, but it's not authenticated with our server. We need to "register" it.

Find Your Registration Token:

Log into your local GitLab server (http://localhost:8080) as the root user.
Click the Admin Area (wrench icon) in the top navigation bar.
In the left sidebar, go to CI/CD > Runners.
Click the "Register an instance runner" button.
Copy the registration token displayed. It will start with glrt...

Run the Interactive Registration Command: We will execute a command inside our running gitlab-runner container:

docker exec -it gitlab-runner gitlab-runner register

Answer the Prompts: This will start an interactive setup.

Here are the answers you should provide:

Enter the GitLab instance URL:

http://gitlab (We use http://gitlab instead of localhost because both containers are on the gitlab-network and can find each other by their container names. 8080 is the port we exposed in Part 1.)
Enter the registration token:

[PASTE_THE_TOKEN_YOU_COPIED]
Enter a description for the runner:

'My Local Docker Runner (or whatever you want to write)' (This is just a friendly name you'll see in the UI.)
Enter tags for the runner (comma-separated):

docker, local (Tags are very important. This allows you to "tag" your jobs in .gitlab-ci.yml to ensure they run on the correct runner.)
Enter an optional maintenance note:

(Just press Enter to leave this blank.)
Enter the executor:

docker (This is the most important setting. It tells the runner to use Docker to run jobs.)
Enter the default Docker image:

alpine:latest (This is a fallback image to use if a job in your .gitlab-ci.yml doesn't specify its own image:.)

The registration is now complete!

Step 4: Verify Your Runner

Go back to your GitLab browser window (the Admin Area > Runners page) and refresh.

You should now see your new runner listed, with a green circle indicating it is online and ready for jobs.

Optional: You can manually verify that the runner is available to pick up jobs.

docker exec -it gitlab-runner gitlab-runner run

Now, go back to that "pending" pipeline (or push a new commit to trigger one). You will see it get picked up by your new runner and finally switch to "running" and then "passed"!

Conclusion

Congratulations! You now have a complete, end-to-end CI/CD setup on your local machine. You have the Local GitLab Server to manage your code and pipelines, and a GitLab Runner to execute the work.

Hope this tutorial series helps you setup your own local version control!
Next what you can do is deploy this to your server and can access from anywhere!

Enjoy your own Private gitlab!

Decoding Golang Interfaces: Why Your Struct Fits an Interface It Never Met

Ishmam Abir | イシュマム・アビル — Tue, 09 Sep 2025 09:49:30 +0000

If you’re coming to Golang from a language like Java, C#, or other language, you’ve probably run into a piece of code that left you scratching your head. It looks something like this:

package main
import "fmt"

// 1. The Concrete Type
type A struct {
    abc string
}

// 2. The Method attached to the type
func (a *A) f1() {
    fmt.Println("f1 function: ", a.abc)
}

// 3. The Abstract Interface
type I interface {
    f1()
}

// 4. The Consumer Function
func wantsI(i I) {
    i.f1()
}

// 5. The Execution
func main() {
    a := &A{}
    a.abc = "test value"

    // ➡ The "magic" question is right here: ⬅
    wantsI(a) 

    fmt.Println("method executed!...")
}

When you run this, it works perfectly and prints:
f1 function: test value
method executed!...

This leads to the central question that stumps many new Go developers:
Why does this work? The wantsI function clearly states it only accepts a parameter of type I (the interface). Yet, we passed it a, which is a variable of type *A (a pointer to a struct). We never wrote "struct A implements I."

How can a function expecting an interface accept a struct that seemingly has no connection to it?

The answer is the single most powerful and defining feature of the Go language: implicit interface implementation.

Let's break it down how concrete types (structs) implicitly satisfy abstract types (interfaces) & Unlock the power of polymorphism in Go.

🧱 The Building Blocks: Concrete vs. Abstract Types

First, you have to understand the two different kinds of types you created.

1. The Concrete Type: `struct A`

A "concrete type" is a blueprint for a real thing that holds data.

Definition: Your struct A is a concrete blueprint. It describes a block of memory that will be created to hold exactly one piece of data: a string named abc.
Example: When you write a := &A{}, you are building an actual instance of this blueprint. It's a real, tangible thing in your program's memory. Think of it as a specific worker you just hired.

2. The Abstract Type: `interface I`

An "abstract type," or interface, is not a thing. It’s a set of rules—a contract.

Definition: Your interface I holds zero data. It only defines a list of behaviors (methods).
The Contract: This interface says, "I don't care what you are, what data you hold, or where you come from. To be considered an I by the Go compiler, you must provide one behavior: a method called f1() that takes no arguments and returns nothing."

✨ The magic Explained: Go's Implicit Implementation

Here is the entire magic trick, explained.

In language like Java, you must explicitly state your intent: public class MyClass implements MyInterface. You are telling the compiler your intend to follow the contract.

Go doesn't work that way. "Don't tell me what you intend to do. Just show me what you can do."

🔄 The Rule in Go: A type automatically and implicitly implements an interface if it possesses all the methods that the interface requires.

Let's apply this rule to our code:

The Contract (interface I): Requires one method: f1().
The Candidate (type *A): Does our type *A have all the required methods?
The Check: Yes. We defined this exact method: func (a *A) f1(). Its name (f1) and signature (no args, no returns) perfectly match the contract.
The Verdict: Because *A has the f1() method, the Go compiler automatically concludes: "Type *A satisfies interface I."

That's it. There is no step five.

Because *A satisfies I, any variable of type *A (like your a) can be legally passed to any function that requires an I (like wantsI).

Inside the wantsI function, the parameter i is an interface value. Think of it as a box that holds two things:

A label identifying its true, concrete type (in this case, *A).
The data itself (the pointer to your struct).

When i.f1() is called, Go looks in the box, sees the type is *A, and calls the specific f1() method attached to *A.

(Bonus)

⚠️ The Critical Detail: Pointers vs. Values (The "Method Set")

There's one more crucial, expert-level detail here that you got right by default. Notice your method definition:
func (a *A) f1()
This is a pointer receiver.This means the f1() is not attached to the A struct itself, but to a pointer to an A struct (*A). This defines what's called the method set.

The method set for type *A(the pointer) includes f1().✅
The method set for type A(the value) doesn't include f1().❌

This means *A implements I, but the plain A Does NOT ! ✅

This is why your main function must create a pointer (a := &A{}) to work. If you tried to create a value instead, the program would fail to compile.

Example (What Doesn't Work)

func main() {
    // Create a_val as a VALUE (type A), not a pointer
    a_val := A{} 
    a_val.abc = "test value"

    // This line will cause a compile-time error!
    wantsI(a_val) 
}

The compiler will not run while showing this error:
cannot use a_val (variable of type A) as I value in argument to wantsI: A does not implement I (method f1 has pointer receiver)

This error message is the compiler explicitly telling you the logic: A doesn't implement I because its method set is missing f1(), which is only on the pointer type.

💬 Final Takeaway

This design is the genius of Go. Interfaces are not about identity or inheritance (what a thing is). They are about behavior (what a thing can do).

This allows you to write functions like wantsI that are completely decoupled from your concrete data structures like A. You can write 100 different structs, and as long as they all have an f1() method, your wantsI function can accept every single one of them without ever knowing they exist. This is the key to flexible, testable, and maintainable software.

📜 Referance

Automate Github Page Deployment using Vue3/Vite

Ishmam Abir | イシュマム・アビル — Tue, 03 Jun 2025 05:00:46 +0000

In my previous article, I posted about how to publish a website created with Vue/Vite on GitHub Pages. In this follow-up, we'll automate the deployment process using GitHub Actions. This means your webpage will automatically update just by pushing changes to the main branch using git push.

My previous article about setting up GitHub Pages can be found here => Publish a Vue.js 3 / Vite Project on GitHub Pages.

Make sure you've set up your project according to the previous article before proceeding. Once that's done, we can dive into setting up the GitHub Action.

Step 1: Create YML File

First, you'll need to create a specific directory structure in your project's root. This tells GitHub Actions where to find your workflow files.

Create a .github folder in your project's root directory. Inside the .github folder, create another folder named workflows. Finally, inside the workflows folder, create a new file named deploy.yml.

Your folder structure should look like this:

my-project-root/
├── .github/
│   └── workflows/
│       └── deploy.yml
├── src/
├── public/
├── package.json
└── ... (other project files)

This deploy.yml file will contain the instructions for our automated deployment.

Step 2: Set GitHub Secrets

To allow GitHub Actions to push to your repository (specifically to the gh-pages branch), you need to provide secure credentials. We'll use GitHub Secrets for this. You'll need to set up two secrets in your repository's settings:

EMAIL: The email address associated with your GitHub account.
GH_TOKEN: A GitHub Personal Access Token with repository permissions.

Get GitHub Token

To get a GitHub Personal Access Token (PAT):

Go to your GitHub Settings.
Navigate to Developer settings > Personal access tokens > Tokens (classic).
Click on Generate new token (or Generate new token (classic)).
Give your token a descriptive name (e.g., GH_PAGES_DEPLOY).
Select the expiration for your token.
Under Select scopes, check the repo scope. This will grant the token permissions to access and modify your repositories.
Click Generate token.

⚠ Important: Copy the generated token immediately. You won't be able to see it again.

Now, go to your project repository on GitHub:

Click on Settings.
In the left sidebar, navigate to Secrets and variables > Actions.
Click on New repository secret.
For the first secret, enter GH_TOKEN as the Name and paste your copied Personal Access Token into the Secret field. Click Add secret.
Create another secret. Enter EMAIL as the Name and your GitHub email address as the Secret. Click Add secret.

These secrets will be securely accessible within our GitHub Actions workflow.

Step 3: Write Deploy Command

Now, open your deploy.yml file and add the following configuration. This YAML code defines the workflow for deploying your Vue.js project.

name: Deploy Vue.js Project to GitHub Pages

# Controls when the workflow will run
on:
  # Triggers the workflow on push events but only for the main branch
  push:
    branches:
      - main

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "deploy-project"
  deploy-project:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

    # Sets up Node\.js in the environment
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "latest"

      - name: Install dependencies
        run: npm ci

      - name: build project
        run: npm run build

     # Deploys the built project to the gh\-pages branch
      - name: Deploy to GitHub Pages
        run: |
          cd dist
          git config --global user.email "${{ secrets.EMAIL }}"
          git config --global user.name "${{ github.actor }}"
          git init
          git add -A
          git commit -m 'Automated deployment'
          git push -f https://${{ github.actor }}:${{ secrets.GH_TOKEN }}@github.com/${{ github.repository }}.git master:gh-pages
        shell: bash

Here, we've defined a job named deploy-project that will execute several steps to deploy our application:

Checkout code: It checks out our repository's code.
Set up Node.js: It installs the specified (or latest) version of Node.js.
Install dependencies: It runs npm ci to install our project's dependencies. This is generally preferred in CI environments over npm install as it uses the package-lock.json or npm-shrinkwrap.json for more reproducible builds.
Build project: It executes our build script (usually npm run build) to generate the static files in the dist directory.
Deploy to GitHub Pages: This is the core deployment step.
- It navigates into the dist folder (where our built files are).
- Configures Git with the email (from secrets.EMAIL) and username (the GitHub actor who triggered the action).
- Initializes a new Git repository in the dist folder.
- Adds all files, commits them with a message.
- Force pushes the contents of the dist folder to the gh-pages branch of our repository using the GH_TOKEN secret. The HEAD:gh-pages syntax ensures that the current commit of the dist directory becomes the gh-pages branch.

After committing this deploy.yml file to our main branch and pushing it to GitHub, the Action should trigger automatically. We can monitor its progress under the "Actions" tab of your GitHub repository. Any subsequent pushes to main will also trigger this workflow, automatically rebuilding and redeploying our site!
Check the changes at your gh-pages

https://<username>.github.io/<your-repository-name>/

In my case, as my repository name is Portfolio & my username(check your's at profile setting page) is ishmamabir, my url is:
https://ishmamabir.github.io/Portfolio/

By following these steps, we can automate the deployment process!
Every time changes are pushed into the main branch, they are immediately uploaded to the deploy page.

Apply this to your codebase and enjoy! ✨

Publish a Vue.js 3/Vite Project on GitHub Pages

Ishmam Abir | イシュマム・アビル — Tue, 13 May 2025 09:51:45 +0000

Publishing a static website for portfolio or information is cool.We can do it for free using github pages.

This guide will walk you through the process of deploying a Vue.js 3 application built with Vite to GitHub Pages.
In this article first I will deploy a Vuejs project to to github pages. And in the next Part I will automate the deployment process using github actions.

Prerequisites

GitHub Account - We need a GitHub account to create a repository.
Vue.js 3 Project - A Vue.js 3 project created using Vite.
Git - Installed and configured locally.

Initial Process

I won't talk much about about basic initialization as you already know what to do! I am skipping the basics, make sure to initialize them such as:

create vue project using vite(npm create vite@latest)
git repository (from git init to git push)

Lets jump into the project configuration part

Step 1: Configure Your Project for GitHub Pages

When deploying to GitHub Pages, we need to specify the base URL for our application. GitHub Pages serves the site from a subpath based on the repository name(which we created at the beginning), so it's important to adjust the base configuration.

Open vite.config.js and add the base configuration. Replace <your-repository-name> with your actual repository name.

// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  base: '/<your-repository-name>/',  // Add this 
...
//rest you the code
})

You may leave the rest of your code alone, and in production, your links will be automatically prefixed with /<your-repository-name>/.
Let's suppose our repository name is Portfolio. In that case, our project prefix is: /Portfolio/.

This is how our vite.config.js will look like:

Caution: base value is type sensitive. check if your repository name match the base value. For easy understanding, I added P as uppercase in my repository name and base value.

Step 2: Build the Project

Run the build command to prepare the app for deployment:

npm run build

This will generate the optimized static files inside the dist/ folder in your project.

Step 3: Deploy to GitHub Pages

Let's assume that you already push your local repository to the Github(if not, do it now using git push -u origin main).
We need to push all contents of the dist folder to a gh-pages branch of your project. We can do it yourself in the same way you push code to github. Or, lets just follow these commands to push them efficiently.

git subtree push --prefix dist origin gh-pages

This command will push your files & folders from /dist folder to a new or existing gh-pages branch.
Check yor git repository's branch list, you will see a new branch named gh-pages if you executed it for the first time.

ignore other branches, those are created by me.

Step 4: Enable GitHub Pages in the Repository Settings

Go to your GitHub repository.
Navigate to Settings > Pages.
In the Source section,select 'Deploy from a branch', then select the 'gh-pages' branch.

It will automatically update the settings, Your site should now be live at:

https://<username>.github.io/<your-repository-name>/

In my case, as my repository name is Portfolio & my username(check your's at profile setting page) is ishmamabir, my url is:
https://ishmamabir.github.io/Portfolio/

We have successfully published our vuejs3 project to our github pages!
Now I can access this website from anywhere and any device

Alternative to Step 3 !! Install the gh-pages node module

To easily deploy the dist/ folder to GitHub Pages, you can use the gh-pages package. Its easy, shortcut and reduces the hassle of Step 3

5.1: Install `gh-pages`

Install gh-pages as a dev dependency:

npm install gh-pages --save-dev

5.2: Update `package.json` with Deploy Script

dd the deploy script to package.json to deploy the app to GitHub Pages:

{
 "scripts": {
    ... //previous lines
    "deploy": "vite build && gh-pages -d dist"
  }
}

alternatively you can also add this. any one will work fine.

{
 "scripts": {
    ... //previous lines
    "predeploy": "npm run build",
    "deploy": "gh-pages -d dist"
  }
}

your package.json will look like this.

5.3: Run the Deploy Command

Finally, deploy the built project to GitHub Pages by running:

npm run deploy

This will automatically push the contents of the dist/ folder to the gh-pages branch of your repository. You have to do nothing after this, and your changes will be visible to the github page.

N.B.: You can find your url in the page section inside the Settings page(see my settings page's screenshot).

This is how easily i deployed my portfolio to the github pages.

Now, You can also do it !

Set Up Your Own Local GitLab Server | Self-hosted GitLab

Ishmam Abir | イシュマム・アビル — Tue, 29 Oct 2024 05:03:26 +0000

Ever wondered how to run your own Git on local server? Is it even possible? 🤷🏻‍♀️
Ans: Yes, possible

Do you want full control over your repositories, CI/CD pipelines, and user access? Setting up a self-hosted GitLab instance will help!
It may appear difficult, but it's more easier than you think—and I'll walk you through it step by step!

This is the part 1 of Git on localhost! Local GitLab Server series. This article(part 1) contains only the git version control setup on the local machine, We will dive further on the upcoming series.

Why Host Your Own GitLab Server?

While services like GitHub and GitLab.com offer excellent hosted solutions, sometimes you just want full control. Running your own GitLab server can provide:

Complete autonomy over your code and repositories.
Unlimited private repositories without cost.
Custom user access management for your team or projects.
Full control of CI/CD pipelines.
Data privacy and security—everything stays on your machine or network.

Prerequisites

Before we begin, make sure you have the following:

Docker installed (we'll use Docker to easily run GitLab in a container).
Admin privileges on your machine.
Minimum hardware requirements(given here).

Installation Process

Step 0: Install Docker

ignore this step if docker is already installed on your machine.

Install Docker from its official website for your desired OS.
Also, we can use any other open source container management tools (eg: Rancher Desktop) instead of Docker

Tip: Before proceeding to the next step, ensure that Docker is running.

Step 1: Download the GitLab CE Docker Image

Open your terminal and write this command to pull the latest gitlab image

docker pull gitlab/gitlab-ce:latest

By doing this, the GitLab CE image that we need to run the server is downloaded.

Step 2: Create Directories for Persistent Storage

To guarantee that GitLab data (such as repositories, settings, and logs) are saved between restarts, establish folders on your own system for these files.

mkdir -p /code/gitlab/config /code/gitlab/logs /code/gitlab/data

Tips: On Windows, you’ll need to use Windows-style paths:
mkdir D:\code\gitlab\config D:\code\gitlab\logs D:\code\gitlab\data

Step 3: Start the GitLab Container

Now it is time to start the GitLab server!
To launch & configure GitLab within a container, we'll use the docker run command:

docker run --detach 
    --hostname localhost 
    --publish 8443:443 
    --publish 8080:80 
    --publish 6022:22 
    --name gitlab 
    --restart always 
    --volume code/gitlab/config:/etc/gitlab 
    --volume code/gitlab/logs:/var/log/gitlab 
    --volume code/gitlab/data:/var/opt/gitlab 
    gitlab/gitlab-ce

Breakdown

Hostname:
- --hostname localhost: We’ve set the hostname to localhost, which should be fine for local testing. You can change this to a custom domain if needed.
Ports:
- --publish 8443:443: Exposes GitLab’s HTTPS (443) to port 8443 on your host machine.
- --publish 8080:80: Exposes GitLab’s HTTP (80) to port 8080 on your host.
- --publish 6022:22: Exposes SSH access (22) to port 6022 (used for cloning repositories via SSH).
Volumes: The volumes map your local directories to the container.
- --volume code/gitlab/config:/etc/gitlab: Maps the configuration files to the host’s directory.
- --volume code/gitlab/logs:/var/log/gitlab: Stores the logs.
- --volume code/gitlab/data:/var/opt/gitlab: Stores GitLab repositories and other persistent data.

Make sure to replace the code/gitlab/ with the actual absolute path on your system.

Note: on Windows, volume paths need to be D:/code/github/ instead of code/gitlab/for absolute path.

Step 4: Access GitLab Instance

Now that your GitLab container is running, open a web browser and go to http://localhost:8080
You should see the GitLab login screen! Since this is the first time you're logging in, The initialization process could take a lengthy time. You can monitor this process with:

docker logs -f gitlab

After that, you will see this page:

For logging in for the very first time, GitLab provides a default user root and its password.
The default password can be found inside the /etc/gitlab/initial_root_password.
Run the below command to get the password:

docker exec -it gitlab cat /etc/gitlab/initial_root_password

Or, you can use this:

docker exec -it gitlab grep 'Password:' 
/etc/gitlab/initial_root_password

Note: This password file will delete automatically when the first container restart happens afer 24 hours.

After login, This will be our homepage:

Our Project installation is completed. Now We can use this as our local git without internet.
In the next article, i will try push a small test project to our local git server & clone from there.

Alternative Approach

In the Installation Process, we install the server by running several docker commands in our cli.
But now in this approach, we can replace the Step 1 & Step 3 by adding a docker-compose file.

This procedure has been recommended by the GitLab documentation.

Create a docker-compose.yml file & copy this below lines:

version: '3.8'

services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    container_name: gitlab
    restart: always
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # Add any other gitlab.rb configuration here, each on its own line
        external_url 'http://localhost:8080'
        gitlab_rails['gitlab_shell_ssh_port'] = 6022
        gitlab_rails['time_zone'] = 'Asia/Tokyo'

    hostname: localhost
    ports:
      - "8443:443"   # HTTPS
      - "8080:80"    # HTTP
      - "6022:22"    # SSH for Git access
    volumes:
      - code/gitlab/config:/etc/gitlab   # Configuration storage
      - code/gitlab/logs:/var/log/gitlab  # Logs storage
      - code/gitlab/data:/var/opt/gitlab  # Data storage (repositories, etc.)

Note: For Windows, change path to C:/path/to/code/gitlab/** instead of code/gitlab/**

In the same directory as docker-compose.yml, Run the docker compose command to start GitLab:

docker compose up -d

Common Troubleshooting Tips

If you get a 404 Page Not Found or have issues accessing GitLab, here are some things to check:

Is the container running?: Run docker ps to verify the GitLab container is up. If not, check the logs with docker logs gitlab to troubleshoot.
Wait for initialization: GitLab can take several minutes to initialize on first launch. Check the container logs with docker logs -f gitlab and wait for the message saying GitLab is ready.
Check port mappings: Ensure you’re accessing the correct ports (80 for HTTP or 443 for HTTPS). If there's a conflict, adjust the ports in the docker run command.
Firewall/Antivirus: On Windows, ensure Docker is allowed through the firewall and no other security software is blocking the ports.

🎉 Now We have finished configuring our self-hosted GitLab server. We can now manage our code using this as our git server.
In the upcoming sections, we will commit a project onto our local self-hosted GitLab server and set up a CICD pipeline on it.
Let's catch up on the next section! ✨

Swithing Data Types: Understanding the 'Type Switch' in GoLang

Ishmam Abir | イシュマム・アビル — Tue, 18 Jun 2024 08:27:31 +0000

Type switches in Golang offer a robust mechanism for handling different types within interfaces. They simplify the code and enhance readability, making it easier to manage complex logic based on type assertions. Whether you are dealing with polymorphic data structures or custom error types, type switches provide a clean and effective solution.

TL;DR:

It allows executing different code based on the type of an interface value, using the syntax switch v := x.(type) { case T1: /.../ case T2: /.../ default: /.../ }

What is a Type Switch?

A type switch is a construct that permits the switching over the types of an interface value. Unlike a regular switch statement that evaluates expressions to find a matching case, a type switch is used to compare the type of a variable. This is particularly useful when you are working with interfaces and need to handle different types differently.

Syntax of Type Switch

The syntax of a type switch in Go is similar to that of a regular switch statement but includes a special .(type) assertion. Here is the basic structure:

switch v := x.(type) {
case T1:
    // v has type T1
case T2:
    // v has type T2
default:
    // no match; v has type of the interface value x
}

In this structure:

x is the interface value whose dynamic type is being inspected.
v is the variable that will hold the value of x in the respective case.
T1, T2, etc., are the types being checked against.

Example

An example according to the syntex is given below

package main

import "fmt"

func SelectType(value interface{}) {
    switch value.(type) {
    case string:
        fmt.Printf("%v is String Type\n", value)
    case int:
        fmt.Printf("%v is int type\n", value)
    case float64:
        fmt.Printf("%v is float type\n", value)
    default:
        fmt.Printf("type of %v is not defined\n", value)
    }
}

func main() {
    SelectType("cow")
    SelectType(3.1416)
    SelectType(true)
}

Output:

cow is String Type
3.1416 is float type
type of true is not defined

Here, Data type of an interface is showing using the Type switch.

Real-life Example

Consider a scenario in a web application where you need to handle different types of errors in a custom way. Go's error handling can be enhanced using type switches to provide more detailed error processing.

package main

import (
    "fmt"
    "net"
    "os"
)

// Custom error types
type NetworkError struct {
    Op  string
    Err error
}

func (e *NetworkError) Error() string {
    return fmt.Sprintf("network error: %s: %v", e.Op, e.Err)
}

type FileError struct {
    Path string
    Err  error
}

func (e *FileError) Error() string {
    return fmt.Sprintf("file error: %s: %v", e.Path, e.Err)
}

func handleError(err error) {
    switch e := err.(type) {
    case *NetworkError:
        fmt.Println("Handling network error:", e)
    case *FileError:
        fmt.Println("Handling file error:", e)
    default:
        fmt.Println("Handling general error:", e)
    }
}

func main() {
    // Simulate different errors
    netErr := &NetworkError{Op: "dial", Err: net.UnknownNetworkError("tcp")}
    fileErr := &FileError{Path: "/invalid/path", Err: os.ErrNotExist}

    handleError(netErr)
    handleError(fileErr)
    handleError(fmt.Errorf("a general error"))
}

In this real-life example, handleError function uses a type switch to handle different custom error types (NetworkError and FileError) and provides specific messages for each type of error.

Output:

Handling network error: network error: dial: unknown network tcp
Handling file error: file error: /invalid/path: file does not exist
Handling general error: a general error

Conclusion

Hopefully this example will make a clear vision where we can use the type switch in our development work.

DEV Community: Ishmam Abir | イシュマム・アビル

CI/CD on Local Gitlab server| Setup GitLab Runner | Self-hosted GitLab

What is a GitLab Runner and Why Do We Need One?

Installation Process

Step 0: Create a Docker Network

Step 1: Pull the GitLab Runner Docker Image

Step 2: Start the Runner Container

Step 3: Register the Runner

Step 4: Verify Your Runner

Conclusion

Decoding Golang Interfaces: Why Your Struct Fits an Interface It Never Met

🧱 The Building Blocks: Concrete vs. Abstract Types

1. The Concrete Type: struct A

2. The Abstract Type: interface I

✨ The magic Explained: Go's Implicit Implementation

⚠️ The Critical Detail: Pointers vs. Values (The "Method Set")

Example (What Doesn't Work)

💬 Final Takeaway

📜 Referance

Automate Github Page Deployment using Vue3/Vite

Step 1: Create YML File

Step 2: Set GitHub Secrets

Get GitHub Token

Step 3: Write Deploy Command

Publish a Vue.js 3/Vite Project on GitHub Pages

Prerequisites

Initial Process

Step 1: Configure Your Project for GitHub Pages

Step 2: Build the Project

Step 3: Deploy to GitHub Pages

Step 4: Enable GitHub Pages in the Repository Settings

Alternative to Step 3 !! Install the gh-pages node module

5.1: Install gh-pages

5.2: Update package.json with Deploy Script

5.3: Run the Deploy Command

Set Up Your Own Local GitLab Server | Self-hosted GitLab

Why Host Your Own GitLab Server?

Prerequisites

Installation Process

Step 0: Install Docker

Step 1: Download the GitLab CE Docker Image

Step 2: Create Directories for Persistent Storage

Step 3: Start the GitLab Container

Breakdown

Step 4: Access GitLab Instance

Alternative Approach

Common Troubleshooting Tips

Swithing Data Types: Understanding the 'Type Switch' in GoLang

TL;DR:

What is a Type Switch?

Syntax of Type Switch

Example

Real-life Example

Conclusion

1. The Concrete Type: `struct A`

2. The Abstract Type: `interface I`

5.1: Install `gh-pages`

5.2: Update `package.json` with Deploy Script