CI/CD

Jenkins builds that show up where your team already is.

The GForge Jenkins Plugin reports every build back to GForge automatically — on the ticket whose code triggered it, and on the project as a whole. No separate dashboard to check, no extra tool to open.

Point Jenkins at GForge. That’s the whole setup.

Install the plugin once. From then on, any Jenkins job whose Git remote points at your GForge instance reports automatically — no Jenkinsfile changes, no per-job setup.

GForge ticket timeline showing two build results — Passed and Failed — each linked back to the Jenkins build that produced it

Build results, right on the ticket whose code triggered them.

Every build posts its pass/fail result straight to the ticket tied to the branch that triggered it — complete with a link back to the full Jenkins log. Nobody has to remember to check; it’s already sitting in the ticket’s timeline, next to the commits and comments that led to it.

The whole build history, without opening Jenkins.

Ticket-level detail is only half the picture. Every GForge project also keeps its own build history — a real, structured record, not a log dump.

GForge project Builds list filtered to a single job, with a filter panel (Job Name, Job Description, Build Description, Changelog, Build Number, Build Result) and a sortable, paginated table of pass/fail build results

Every build for a job, filtered and sorted — no separate tool required.

Filter by job name, build number, changelog contents, or result — go back as far as you need. If you just want to know whether the last ten builds are green, it’s one page, and it isn’t Jenkins.

Any number of Jenkins instances. Zero registration.

Point ten Jenkins controllers at the same GForge project — or run an autoscaled fleet of them in the cloud — and every one reports in immediately. There’s no pairing step and nothing to register.

Jenkins Controller 1
Jenkins Controller 2
Jenkins Controller 3
Your GForge Project

Authorization is scoped by GForge user credentials and project permissions, not by a registered Jenkins instance — which is exactly what makes cloud-based, autoscaled Jenkins workers practical. Give a fresh worker its credentials and it’s reporting build activity from its first build. No fleet management required on GForge’s side. (Using distinct credentials per controller keeps attribution accurate — GForge credits a build to the user whose credentials reported it.)

Beyond build status

FRS File Sync, Built Into the Pipeline

Pull dependencies from a GForge File Release System release before the build with gfrsDownload, and publish artifacts back with gfrsUpload when it’s done — with add, replace, or skip collision handling.

Every Job Type Supported

Freestyle, Declarative Pipeline, Scripted Pipeline, and Multibranch Pipeline jobs all work out of the box. Multibranch jobs resolve the branch’s SCM source automatically at build time.

Deployment Events, Not Just Builds

A build passing isn’t the same as code being live somewhere. Deploy a revision and GForge automatically finds every open ticket in it and stamps a deployment event, tagged to the environment — a separate signal from the Version Control Promotion Model, which infers status from git branch state instead. Any tool can call it, not just Jenkins.

Self-Hosted, No Cloud Dependency

Every call the plugin makes targets your own GForge instance’s URL directly. There’s no relay, no proxy, and no hardcoded external hostname it phones home to.

Authenticate With GForge

Configure Jenkins to authenticate logins against your GForge instance — one less set of credentials for your team to keep in sync.

No Source Code Transmitted

What gets sent to GForge is the build result, console output, and a changelog of commit SHAs, authors, and messages — never file diffs or file contents.

Ready to install it? Get the GForge Jenkins Plugin →

See your own builds land in GForge.

Start free, or talk to an engineer about connecting your existing Jenkins setup.