• Cilium Website
  • Table of Contents
  • Contributing
  • Getting Started
  • Usage
    • Run the website
    • Build the website
    • Run the built website
    • Clean Gatsby cache
  • Project Structure
  • Component Folder Structure
    • Each component includes
    • Each component optionally may include
    • Example structure
  • Code Style
    • ESLint
    • Prettier
    • VS Code
    • Development Commands
  • How to create blog post

Please see Contributing for guidelines on adding blogs, documentation, Cilium distributions and trainings, or any other content to the website.

1. Fork this repository and clone the forked one

git clone [email protected]:<your-handle>/cilium.io.git

2. Install dependencies

npm install

3. Copy .env.example and rename it into .env

cp .env.example .env

Note: This project includes a Makefile with all the development commands.

You can quickly set up the project using:

make env     # Setup environment file
make install # Install dependencies
make start   # Start the development server

Explore the Development Commands section for more available options.

npm run start

Note: If you encounter the error:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

This happens because Node.js has a default memory limit (usually around 4 GB), which may not be sufficient for memory intensive tasks such as image processing in Gatsby.

To fix this, increase the memory limit by running the following command:

Linux/macos:

NODE_OPTIONS="--max-old-space-size=8192" npm run start

Windows:

$env:NODE_OPTIONS="--max-old-space-size=8192"
npm run start

This allows Node.js to use up to 8 GB of RAM. You can adjust the number (8192) if needed based on your system capacity.

Tip for laptops without fans (e.g., MacBook Air):
To reduce heat and memory usage during development, you can limit Gatsby to fewer CPU cores:

NODE_OPTIONS="--max-old-space-size=6144" GATSBY_CPU_COUNT=2 npm run develop

npm run build

npm run serve

npm run clean

├── src
│   ├── components
│   │  ├── pages — React components that are being used specifically on a certain page
│   │  └── shared — React components that are being used across the whole website
│   ├── hooks
│   ├── images — Images that are being quired using graphql. Read more about it here — gatsbyjs.org/docs/working-with-images. Also note, that folder structure should be equal to the structure of components folder
│   ├── pages
│   ├── styles
│   ├── templates
│   ├── utils
│   └── html.js — HTML template for all generated pages. Read more about it here — gatsbyjs.org/docs/custom-html
├── static
│   └── fonts - Self-hosted fonts
├── gatsby-browser.js — This file is where Gatsby expects to find any usage of the Gatsby browser APIs (if any). These allow customization/extension of default Gatsby settings affecting the browser. Read more about it here — gatsbyjs.org/docs/browser-apis
├── gatsby-config.js — This is the main configuration file for a Gatsby site. This is where you can specify information about your site (metadata) like the site title and description, which Gatsby plugins you’d like to include, etc. Read more about it here — gatsbyjs.org/docs/gatsby-config
├── gatsby-node.js — This file is where Gatsby expects to find any usage of the Gatsby Node APIs (if any). These allow customization/extension of default Gatsby settings affecting pieces of the site build process. Read more about it here — gatsbyjs.org/docs/node-apis
└── gatsby-ssr.js — This file is where Gatsby expects to find any usage of the Gatsby server-side rendering APIs (if any). These allow customization of default Gatsby settings affecting server-side rendering. Read more about it here — gatsbyjs.org/docs/ssr-apis

1. Main JavaScript File
2. Index File

1. Folder with icons and images

Also, each component may include another component that follows all above listed rules.

component
├── nested-component
│  ├── images
│  │  ├── image.png
│  │  └── icon.svg
│  ├── nested-component.jsx
│  └── index.js
├── images
│  ├── image.png
│  └── icon.svg
├── component.jsx
└── index.js

ESLint helps find and fix code style issues and force developers to follow same rules. Current configuration is based on Airbnb style guide.

Additional commands:

npm run lint

Run it to check the current status of eslint issues across project.

npm run lint:fix

Run it to fix all possible issues.

Prettier helps to format code based on defined rules. Difference between Prettier and ESLint.

Additional commands:

npm run format

Run it to format all files across the project.

Following extensions required to simplify the process of keeping the same code style across the project:

• ESLint
• Prettier

After installation enable "ESLint on save" by adding to your VS Code settings.json the following line:

"editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
}

You can navigate to settings.json by using Command Pallete (CMD+Shift+P) and then type "Open settings.json".

To enable Prettier go to Preferences -> Settings -> type "Format". Then check that you have esbenp.prettier-vscode as default formatter, and also enable "Format On Save".

Reload VS Code and auto-format will work for you.

This project uses a Makefile to simplify common tasks. Below are the available commands:

make install       # Install dependencies
make env           # Setup environment file (.env)
make start         # Start dev server (fast, skips image processing)
make start-full    # Start dev server (full build with image processing)
make build         # Build the site for production
make serve         # Serve production build locally
make clean         # Clean Gatsby cache
make lint          # Run ESLint linter
make lint-fix      # Fix ESLint issues

make docker-build   # Build the Docker image
make docker-run     # Run the project inside Docker (production mode)
make docker-run-dev # Run the project inside Docker (development mode with hot reload)
make docker-shell   # Open a shell inside the Docker container

The blog is created using gatsby-source-filesystem plugin and gatsby-plugin-mdx along with the createPages Gatsby Node API. The blog is configured to dynamically create pages with .md files from src/posts/.

In .md files we can declare frontmatter at the beginning:

• path: the path of blog post;
• date: the publish date of blog post;
• title: the title of blog post;
• isPopular: the boolean value that defines posts in block Popular posts;
• isFeatured: the boolean value that defines the post in block Featured Story (NOTE: featured post can be only 1);
• draft: the boolean value that defines the post is still in the process of being written. (it's false by default, if it's true, the post will not be rendered on production, but only on localhost);
• categories: the categories of blog post;
• tags: the tags of blog post, which is displayed in Twitter share card;
• ogImage: the og:image in SEO metadata, also it is the cover image, which is displayed in the blog post card (featured story, popular posts);
• ogSummary: the og:description in SEO metadata, also it is the description text, which is displayed in the blog post card (featured story, popular posts).
• externalUrl: the external blog post url
• ogImageUrl: the image url for the og:image in SEO metadata (use for the external blog posts)

The preview tags in .md files (which is used in the old Cilium blog) are fully converted to ogImage and ogSummary in frontmatter.

---
path: "/blog/2021/10/13/cilium-joins-cncf"
date: "2021-10-13T17:00:00.000Z"
title: "Cilium joins the CNCF"
isPopular: true
isFeatured: false
draft: false
ogImage: cilium-cncf-card.png
ogSummary: "CNCF TOC chair Liz Rice explains why she's excited about the future of
Cilium as an Incubation project in the CNCF." 
categories:
  - Technology
  - Community
tags:
  - eBPF
  - BPF
  - Cilium
  - CNCF
---

import authors from 'utils/author-data.js';

![Cilium joins the CNCF](cilium-cncf-card.png)

I'm beyond thrilled that Cilium has joined the CNCF as an Incubation project!
I'm excited about it not just as an advocate for the Cilium project, but also as
an Isovalent team member, and in my role as Chair of the CNCF's Technical
Oversight Committee - and I'd like to share why.

In .md files, it's able to use the custom component Blog Author and pass header, bio as props to the component. For example:

<BlogAuthor
header="Thomas Graf"
bio={`Thomas Graf is a Co-Founder of Cilium and the CTO & Co-Founder of <a href="https://isovalent.com">Isovalent</a>, the company behind Cilium. Before that, Thomas spent 15 years as a kernel developer working on the <a href="https://kernel.org">Linux kernel</a> in networking, security and eventually eBPF.`}
/>

Or you can import the author data in .md files from src/utils/author-data.js:

import authors from 'utils/author-data';

<BlogAuthor {...authors.thomasGraf}/>

The default theme of Blog Author is primary.

If you want to use another theme, pass the prop theme with value secondary:

<BlogAuthor
theme="secondary"
header="Guest Blog Post:"
bio={`This is a guest blog by a Cilium user based on the <a href="https://davidlovezoe.club/wordpress/archives/851">the original blog post</a>. If you would like to publish a blog post as well, contact us on Slack.`}
/>