# Selenium website repository setup and publishing > SeleniumHQ/seleniumhq.github.io contains the Hugo source for selenium.dev, including official documentation and examples. It is aimed at documentation contributors and Selenium project maintainers, not developers who only need to install Selenium. **SeleniumHQ/seleniumhq.github.io** — Official Selenium website and documentation - Repository: https://github.com/SeleniumHQ/seleniumhq.github.io - Website: https://selenium.dev - Stars: 1,403 · Forks: 1,584 - Language: HTML - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/seleniumhq-seleniumhq-github-io ## What SeleniumHQ/seleniumhq.github.io contains This repository solves a publishing and documentation problem for the Selenium project. Its output is the official website at https://selenium.dev, while its source includes the website, project documentation, and examples organized for Java, Kotlin, Python, JavaScript, Ruby, and .NET. Its users are Selenium documentation contributors, website maintainers, and developers who want their examples included in the official documentation workflow. It is not the main source repository for the Selenium WebDriver libraries. Installing Selenium into a test project and using Selenium to automate a browser do not require cloning this site. This distinction matters when choosing a repository. SeleniumHQ/seleniumhq.github.io builds documentation with Hugo and the Docsy theme, while the browser automation documentation published by the site may direct readers toward separate language packages. The repository uses `trunk` as its default and source branch. It also contains a Gitpod configuration, contribution guidance, governance files, build scripts, GitHub Actions workflows, and a `website_and_docs` directory containing the site project. There are no GitHub releases associated with this repository. Its maintenance status should therefore be judged from repository activity rather than an application-style release stream. The last push was on 2026-10-14. ## How Hugo and Docsy build selenium.dev The site is generated with Hugo and rendered through the Docsy theme. The README specifically requires Hugo's extended Sass/SCSS build, rather than an ordinary binary without those compilation features. It recommends Hugo 0.168.0. Go and Node.js are also prerequisites, with the README identifying Node.js LTS 24 as the expected version. Docsy 0.16.0 changed how Bootstrap and Font Awesome are supplied. The README says these theme assets now arrive as npm packages instead of Hugo modules. That design explains why `npm install` is mandatory. Skipping it causes the Hugo build to fail with SCSS import errors. The generated package metadata under `packages/hugoautogen` is therefore part of the dependency setup, not an optional cache. The repository has separate GitHub Actions workflows for examples in Java, Kotlin, Python, JavaScript, Ruby, and .NET. The README describes these as example-running workflows, which means documentation examples receive language-specific CI treatment. The top-level `examples` directory also includes `examples/selenium-server-4.51.0.jar`. Based on the repository layout, this file is a bundled example artifact, but the README does not describe its command-line invocation or role in local development. ## Preparing a local site checkout The documented local path starts with installing Hugo, following the Docsy Get Started instructions, installing Go, and installing Node.js LTS 24. Hugo must be the extended Sass/SCSS build. Clone the repository, change into the site project, install npm dependencies, and start Hugo's local server. The following commands reproduce the setup sequence stated in the README: ```bash cd website_and_docs npm install hugo server ``` The first command enters the Hugo project rather than the repository root. `npm install` installs the npm packages required by the Docsy theme assets. `hugo server` then starts the local development server using the site's Hugo configuration. The README does not specify the URL printed by Hugo or a required browser driver setup for the site itself, so no local URL or driver command should be invented. If the Docsy version changes, the README requires refreshing the generated package directory before installing dependencies again. It gives this exact maintenance command: ```bash hugo mod npm pack ``` That command should be run when the theme dependency changes, not as a substitute for understanding the documented order. The repository also provides a Gitpod option for contributors who do not want to clone and configure the project locally. The README links that option through the `Open in Gitpod` badge and `.gitpod.yml`. ## Testing documentation examples across languages Example validation is split by language rather than handled as one undifferentiated check. The README badges identify workflows for Java, Kotlin, Python, JavaScript, Ruby, and.NET examples. Each workflow is represented by a dedicated file under `.github/workflows`, including `java-examples.yml`, `kotlin-examples.yml`, `python-examples.yml`, `js-examples.yml`, `ruby-examples.yml`, and `dotnet-examples.yml`. This arrangement matters for contributors who edit examples. A documentation change can be syntactically acceptable while still failing the checks associated with its language. The repository's CI configuration is the appropriate place to determine the exact commands, runtime versions, working directories, and browser setup for each example. The README does not reproduce those workflow internals, so they are not specified here. The project also includes an `examples/selenium-server-4.51.0.jar` file. Its presence indicates that the examples directory includes a Selenium Server artifact, but the documentation does not say whether contributors should launch it for every example, which examples depend on it, or what arguments it requires. A contributor should inspect the relevant workflow and example files rather than assume a generic server command. This repository therefore treats documentation code as CI-managed content. That is different from a normal documentation-only repository where examples may be illustrative snippets. The presence of language-specific workflows creates a clear maintenance obligation for edits that change runnable examples. ## How trunk becomes the published selenium.dev site GitHub Actions runs for every commit on each pull request and protected branch. The regular CI execution builds the site with Hugo to verify that the commit works. The README identifies `.github/workflows/test.yml` as the pull-request testing workflow and `.github/workflows/deploy.yml` as the deployment workflow. Deployment has an unusual two-branch structure. The source files are maintained in `trunk`, while generated and published files are pushed to `publish`. After CI runs for `trunk`, `build-site.sh` checks the commit message for the literal marker `[deploy site]`. When that marker is present and the commit is on `trunk`, the deployment workflow builds and deploys the site. The README states that the Selenium-CI user commits the changes to `publish`. The site is deployed through GitHub Pages. The `selenium.dev` domain is managed through Gandi, and the README says PLC or TLC members can help with access. The repository settings contain the GitHub Pages configuration, although that settings page is only accessible to maintainers. This deployment model has a direct consequence for contributors. A successful local build does not by itself publish the site. Publication depends on the commit landing on `trunk` with the required deployment marker and on the deployment workflow succeeding. The README does not document rollback procedures for a failed deployment, so an adopter should not assume that reverting a commit is the complete recovery process. ## Maintenance, licensing, and upgrade costs The repository is licensed under Apache-2.0. That license covers the site source in this repository, but it does not automatically settle the licensing of every external package, bundled binary, linked resource, or example dependency. A contributor modifying content should review the relevant repository files and dependency licenses separately. This is a repository identification point, not legal advice. There are no GitHub releases, so upgrades are not presented as versioned site releases in the repository metadata. The repository is not archived, and its last push was on 2026-10-14, which is recent enough to avoid describing it as abandoned based on the stated maintenance rule. That does not promise a particular release cadence or guarantee every contribution will be merged. Dependency changes can require more than editing a version number. The README says that changing the Docsy version requires `hugo mod npm pack`, followed by `npm install`. The site also depends on Hugo, Go, Node.js, Docsy, Bootstrap, and Font Awesome assets. Its upgrade cost therefore includes checking build compatibility, generated package metadata, Sass compilation, and the language-specific example workflows. The `trunk` and `publish` branch split adds another maintenance consideration. Maintainers need to understand which commits trigger deployment and how generated content reaches the published branch. The README provides the deployment marker and workflow names, but it does not document a rollback command or a formal release procedure. ## Selenium site documentation versus a Selenium installation The closest practical alternative for a developer who only needs Selenium usage documentation is the published site itself, not another local repository. SeleniumHQ/seleniumhq.github.io stores the source used to produce that site and includes the machinery for building and deploying it. A reader who wants to read or copy a guide can use https://selenium.dev without installing Hugo, Go, Node.js, or npm packages. For a team creating automated tests, the alternative is to follow the Selenium documentation for the language and browser bindings relevant to that test project. This repository does not replace those language packages, browser drivers, or a test runner. Its own examples and workflows are designed to validate documentation content, not to serve as a universal application setup. For contributors, another model would be maintaining a private documentation site or a plain static site. That would avoid this repository's specific Docsy and npm asset requirements, but it would not publish changes to selenium.dev. The relevant difference is therefore editorial control: this repository controls official project content and has a defined `trunk` to `publish` workflow, while an independent site cannot feed that official publication branch. The repository is the wrong choice when the goal is only to run one browser test locally. It is the right choice when the intended deliverable is a change to official Selenium documentation or the website. ## Conclusion Adopt this repository if you need to change selenium.dev, review its documentation structure, or maintain its publication process. Do not clone it merely to install Selenium for an automated test suite. Before contributing, verify that the required extended Hugo build, current Docsy package state, and selected example language match your changes. ## FAQ ### How do I install and run the Selenium website locally? Install Hugo's extended Sass/SCSS build, Go, and Node.js LTS 24, then clone the repository. Enter `website_and_docs`, run `npm install`, and start the site with `hugo server`. ### Why does the Selenium website require npm install? Since Docsy 0.16.0, Bootstrap and Font Awesome assets are npm packages rather than Hugo modules. The README says skipping `npm install` makes the build fail with SCSS import errors. ### How does SeleniumHQ/seleniumhq.github.io deploy selenium.dev? CI builds `trunk`, and `build-site.sh` looks for the literal `[deploy site]` marker in a commit on that branch. When the marker is present, the deployment workflow publishes changes through GitHub Pages to the `publish` branch. ### Does this repository contain Selenium browser automation libraries? No. It is the source for the official Selenium website and documentation. The repository builds and publishes selenium.dev, while installing Selenium for application tests requires the relevant Selenium packages and browser setup. ## Sources - [Issues](https://github.com/SeleniumHQ/seleniumhq.github.io/issues) - [License: Apache-2.0](https://github.com/SeleniumHQ/seleniumhq.github.io/blob/trunk/LICENSE) - [Project website](https://selenium.dev) - [README](https://github.com/SeleniumHQ/seleniumhq.github.io/blob/trunk/README.md) - [SeleniumHQ/seleniumhq.github.io on GitHub](https://github.com/SeleniumHQ/seleniumhq.github.io) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/seleniumhq-seleniumhq-github-io