Skip to main content
In this lesson we explore and trigger two Jenkins projects to inspect their configuration and runtime behavior: a Freestyle job that renders ASCII artwork, and a scripted Pipeline job that demonstrates basic stage flow. Both jobs are configured inline in Jenkins (no SCM and no automated triggers), making them ideal examples for understanding job structure and migrating Jenkins logic to other CI/CD systems.

Overview

This walkthrough helps you understand how simple shell-driven Freestyle jobs compare to scripted Pipelines, which is useful when planning migrations (for example, to GitHub Actions).

Generate ASCII Artwork (Freestyle)

This Freestyle job calls the adviceslip API to fetch an advice message, validates the message length using jq and shell tests, and—if the message is long enough—renders it as ASCII art using the cowsay utility.
A dark-themed Jenkins web interface for a job titled "Generate ASCII Artwork," showing the job description and permalinks in the main area with a builds panel and navigation menu on the left.
Configuration notes:
  • No Source Code Management (job is configured without SCM).
  • No automated triggers.
  • Single build step: Execute shell, which performs three logical phases: build, test, deploy.
A dark-themed Jenkins job "Configure" page showing the left navigation (General, Source Code Management, Triggers, etc.) and the main panel with Triggers and Environment options (checkboxes for build triggers, workspace cleanup, timestamps, etc.). The Save and Apply buttons are visible at the bottom.
High-level step behavior:
  • Build: fetch an advice message from adviceslip API and save it to advice.json.
  • Test: extract message with jq and assert it contains more than 5 words; otherwise exit non‑zero to mark the build as failed.
  • Deploy: install and run cowsay (Debian/Ubuntu example) and pipe the advice into a randomly-selected cowfile.
Shell script used in the job:
The script assumes jq and cowsay are available or can be installed with sudo. Installing packages on shared agents can have security and stability implications—prefer pre-baked agent images or containerized runners when possible.
Triggering the job multiple times shows success and failure runs depending on the advice length. Example console output for a successful run (truncated):
Example console output when the advice is too short and the build fails:
This Freestyle job demonstrates:
  • How simple shell logic can control build success/failure.
  • How external APIs and small utility tools (jq, cowsay) are often used in quick demo jobs.
  • Why migrating these jobs may require translating shell steps into equivalent workflow actions or containerized steps.

Scripted Pipeline

Next, inspect a scripted Pipeline job that contains a small hardcoded pipeline script in the Jenkins job configuration (again, no SCM and no triggers). The pipeline shows a simple three-stage flow: Greet, Build, and Results. The pipeline activity page with recent runs:
A Jenkins pipeline web UI showing the "scripted-pipeline" activity page with a list of recent runs (1–7), each marked successful with green checkmarks and durations. The entries show "Started by user siddharth," and the page includes Run/Disable buttons and navigation tabs.
Opening a run shows the stage visualization and console output. The Build stage simulates work with sleep, and Results prints the completion time.
A screenshot of a Jenkins scripted-pipeline run showing stages (Start, Greet, Build, Results, End) with green checkmarks indicating success. The build log lists completed steps including "Pretending to build..." and a 5-second sleep.
Scripted Pipeline used in the job:
When executed:
  • The console shows the greeting, a simulated build pause (5 seconds), and the completion timestamp.
  • The stage view makes it easy to visualize progress and success/failure per stage.

Next steps and migration considerations

  • Later lessons will cover how to migrate these Jenkins jobs (Freestyle and scripted Pipeline) to GitHub Actions and how to express the same logic in workflow files.
  • When planning migration, consider:
    • Translating shell-driven Freestyle steps to individual CI actions or container steps.
    • Replacing inline package installs with prebuilt images or setup actions to avoid privileged operations on runners.
    • Converting scripted Pipeline stages into YAML-based workflows and grouping steps into reusable actions.
References:

Watch Video