Freestyle jobs are Jenkins' simplest project type: fill a form, add build steps, run.
Use them for simple tasks like running shell scripts, copying files, or triggering other jobs.
No Jenkinsfile or pipeline code required – just point-and-click configuration.
Best for beginners or quick automation where complexity isn't needed.
Limitations: no version control integration, complex logic is painful, no parallel stages.
Production tip: always use parameterized builds and archive artifacts for traceability.
Security: restrict job configuration to admins; use credentials binding for secrets.
Migrate to Pipeline jobs when you need branching, stages, or resilience.
✦ Definition~90s read
What is Jenkins Freestyle Jobs?
A Jenkins Freestyle Job is the most basic project type in Jenkins. You configure it entirely through the web UI: set source code management (e.g., Git), define build triggers (e.g., cron, webhook), add build steps (shell, Windows batch, Ant, Maven), and post-build actions (archive artifacts, publish test reports, email notifications).
★
Think of a Jenkins Freestyle job like a recipe card.
No code, no pipeline-as-code – just a form. It's perfect for simple, linear workflows. Internally, Jenkins creates a workspace, checks out code, runs your steps sequentially, and collects results. The job configuration is stored in XML on the master node.
This simplicity is both its strength and weakness. You can create a CI pipeline in minutes, but you can't version control the configuration easily, and complex logic (loops, conditions, parallel execution) requires plugins or messy shell scripts.
Plain-English First
Think of a Jenkins Freestyle job like a recipe card. You write down the ingredients (source code, tools) and the steps (compile, test, deploy). Jenkins follows the card exactly every time you ask. It's not a smart chef that can improvise – it just does what the card says. That's fine for simple dishes, but if you need to adapt based on taste (branch, environment), you need a more dynamic recipe (Pipeline as Code).
I remember my first Jenkins job. I was a junior dev, and the CI server was this mysterious black box that 'the ops team' managed. One day, I needed to automate a build, and someone said 'just create a freestyle job.' I clicked around, added a shell step with 'make && make test', and hit save. It worked. That moment hooked me. Freestyle jobs are the gateway drug to CI/CD. They're not fancy, but they get the job done. Over the years, I've seen teams run thousands of freestyle jobs in production – simple, reliable, and easy to debug. But I've also seen them become a tangled mess. This guide will show you how to use them right, avoid common pitfalls, and know when to move on.
1. What is a Jenkins Freestyle Job?
A Jenkins Freestyle Job is the simplest project type in Jenkins. It allows you to configure a build pipeline entirely through the web UI without writing any code. You specify the source code location (e.g., Git repository), triggers (e.g., cron, webhook, or manual), build steps (shell commands, Windows batch, Maven targets, etc.), and post-build actions (archive artifacts, publish JUnit test results, send emails). The job runs sequentially: checkout, build, test, archive. It's ideal for straightforward automation tasks like compiling a project, running unit tests, or deploying to a staging server. However, because the configuration is stored in XML on the master node, it's not easily version-controlled. For complex workflows (parallel stages, conditional logic, loops), you'd want to use Pipeline jobs. But for getting started quickly, Freestyle jobs are perfect.
To create one: click 'New Item' > enter name > select 'Freestyle project' > OK. Then you'll see a form with sections: General, Source Code Management, Build Triggers, Build Environment, Build, Post-build Actions. Fill them out and save. That's it.
📊 Production Insight
In production, always use parameterized builds (e.g., $BRANCH, $ENV) to make jobs reusable. Archive artifacts with a pattern like */target/.jar to capture outputs. Set a build discarder to keep last 10 builds to save disk space.
🎯 Key Takeaway
Freestyle jobs are the quickest way to automate a build. Use them for simple, linear pipelines. For anything complex, consider Pipeline as Code.
thecodeforge.io
Jenkins Freestyle Jobs
2. Setting Up Source Code Management
The Source Code Management (SCM) section tells Jenkins where your code lives. The most common is Git. Enter the Repository URL (e.g., https://github.com/yourorg/yourrepo.git). You can specify credentials (username/password or SSH key) by adding a Jenkins credential. For branches, you can specify */main or use a parameter like $BRANCH. Other options: Subversion, Mercurial, or 'None' if you don't need checkout.
Production tip: Always use specific branch specifiers, not '**' which can cause unexpected builds. Use 'Poll SCM' trigger to check for changes periodically. For Git, you can also use webhooks (e.g., GitHub plugin) for instant triggering.
Example: In the 'Branches to build' field, put /main to build only the main branch. If you want to build all feature branches, use * but be careful – it can flood your CI.
Credentials: Click 'Add' next to Credentials. Choose 'Jenkins' domain. Select kind: 'Username with password' or 'SSH Username with private key'. Enter your credentials. Test connection by clicking 'Validate'.
📊 Production Insight
Use SSH keys instead of passwords for Git. They're more secure and don't expire. Store the private key in Jenkins credentials. Also, set 'Clean before checkout' to avoid stale files from previous builds.
🎯 Key Takeaway
Configure SCM with specific branches and proper credentials. Use webhooks for instant builds instead of polling.
3. Build Triggers: When to Run Your Job
Build triggers define what starts a build. Options
Build periodically: Cron syntax. E.g., H/15 runs every 15 minutes. The 'H' is a hash to distribute load.
Poll SCM: Check SCM for changes at a schedule. E.g., H/5 polls every 5 minutes. If changes detected, build starts.
GitHub hook trigger for GITScm polling: If you have GitHub plugin, GitHub can notify Jenkins on push.
Trigger builds remotely: Allows triggering via URL with authentication token. Useful for scripts.
Build after other projects are built: Chain jobs. E.g., build 'deploy' after 'test' succeeds.
Production: Avoid frequent polling (every 1 minute) – it wastes resources. Use webhooks when possible. For periodic builds (e.g., nightly), use 'Build periodically' with a hash to avoid all jobs starting at the same time.
Example: To run a nightly build at 2 AM, use H 2 . To run every hour, use H *.
📊 Production Insight
If you have many jobs polling the same SCM, use the 'Poll SCM' trigger with a hash. Better yet, use a single 'Multibranch Pipeline' to trigger all branches efficiently.
🎯 Key Takeaway
Choose triggers wisely: webhooks for instant feedback, periodic for scheduled tasks, and avoid aggressive polling.
thecodeforge.io
Jenkins Freestyle Jobs
4. Build Environment: Setting Up the Workspace
The Build Environment section configures the workspace before build steps run. Common options: - Delete workspace before build starts: Ensures clean state. Useful to avoid leftover files. - Use secret text(s) or file(s): Bind credentials as environment variables. E.g., AWS_ACCESS_KEY_ID. - Add timestamps to the Console Output: Prepend each line with timestamp for debugging. - Set Build Name: Customize build display name (e.g., #${BUILD_NUMBER}-${BRANCH}). - Abort the build if it's stuck: Set timeout (e.g., 10 minutes).
Production: Always delete workspace before build if your build doesn't handle incremental builds. Use credentials binding instead of hardcoding secrets. Set a timeout to prevent hung jobs.
Example: Check 'Delete workspace before build starts' and 'Add timestamps to the Console Output'. For credentials, click 'Add' and select the credential ID.
📊 Production Insight
In a shared Jenkins node, deleting workspace is critical to avoid cross-job contamination. Use the 'Node and Label Parameter' plugin to run jobs on specific agents if needed.
🎯 Key Takeaway
Configure build environment for cleanliness and security. Delete workspace, bind secrets, and set timeouts.
5. Build Steps: The Core of Your Pipeline
Build steps are the actual commands that run. You can add multiple steps; they execute sequentially. Types: - Execute shell: Runs shell commands on Unix nodes. E.g., ./gradlew build. - Execute Windows batch command: For Windows nodes. - Invoke Ant/Maven/Gradle: Use Jenkins-installed tools. - Run with timeout: Wraps a step with a timeout.
Example: Add an 'Execute shell' step with: `` #!/bin/bash set -e echo "Building branch ${BRANCH}" ./mvnw clean install -DskipTests ` The set -e ensures the build fails on first error. Always use #!/bin/bash` shebang for consistency.
Production: Keep build steps simple. If you need complex logic, put it in a script file in your repo and call it (e.g., ./ci/build.sh). This makes it version-controlled and testable.
📊 Production Insight
Avoid inline shell scripts with complex logic – they're hard to debug and not versioned. Instead, commit a script in your repo and invoke it. Use 'set -e' and 'set -x' for debugging.
🎯 Key Takeaway
Build steps are the heart of a freestyle job. Keep them simple, use scripts from repo, and fail fast with 'set -e'.
6. Post-Build Actions: What Happens After the Build
Post-build actions run after the build completes, regardless of success or failure (some actions can be conditional). Common actions: - Archive the artifacts: Save files (e.g., JARs, WARs) for later use. Pattern: */target/.jar. - Publish JUnit test result report: Parse test XMLs and show trends. Pattern: */target/surefire-reports/.xml. - Record fingerprints of files to track usage: Useful for dependency tracking. - Build other projects: Trigger downstream jobs. E.g., trigger 'deploy' only if build successful. - Publish over SSH/CIFS: Copy artifacts to remote servers. - Email notification: Send build results to recipients.
Production: Always archive artifacts for traceability. Configure 'Discard old builds' to avoid disk bloat. Use conditional triggers (e.g., trigger downstream only on success). Set email thresholds (e.g., only on failure or unstable).
Example: In 'Archive the artifacts', enter */target/.jar. In 'Publish JUnit test result report', enter */target/surefire-reports/.xml.
📊 Production Insight
If you archive too many builds, disk fills up. Set a discarder to keep last 10 builds and delete artifacts older than 7 days. Use 'Fingerprint' to track artifact usage across jobs.
🎯 Key Takeaway
Post-build actions handle results and notifications. Archive artifacts, publish test reports, and trigger downstream jobs conditionally.
7. Parameterized Builds: Making Jobs Reusable
Parameterized builds allow you to pass variables into the job at runtime. Check 'This project is parameterized' and add parameters like: - String Parameter: e.g., BRANCH with default value main. - Choice Parameter: e.g., ENV with choices dev,staging,prod. - Boolean Parameter: e.g., SKIP_TESTS. - File Parameter: Upload a file.
In build steps, reference parameters as $BRANCH, $ENV. You can also use them in SCM branch specifier: */$BRANCH.
Production: Parameterize everything: branch, environment, build type. This makes jobs reusable without copying. Use 'Active Choices' plugin for dynamic parameters (e.g., list branches from Git).
Example: Add a String Parameter named BRANCH with default main. In SCM, set Branches to build: */${BRANCH}. In shell step: echo "Building branch ${BRANCH}".
📊 Production Insight
Parameterized builds are essential for production. They allow one job to build any branch or environment. Combine with 'Build with Parameters' to trigger manually.
🎯 Key Takeaway
Use parameters to make freestyle jobs flexible. Always parameterize branch and environment.
8. Managing Credentials Securely
Never hardcode secrets in build steps. Jenkins Credentials plugin stores secrets securely. Add credentials via 'Credentials' > 'System' > 'Global credentials' > 'Add Credentials'. Types: Username with password, SSH key, secret text, certificate.
In a freestyle job, use 'Bindings' in Build Environment to expose credentials as environment variables. For example, add a 'Secret text' credential for an API token, bind it as API_TOKEN. Then in shell: curl -H "Authorization: Bearer $API_TOKEN" ....
For Git over SSH, add an SSH key credential and select it in SCM.
Production: Use separate credentials per service. Rotate them regularly. Use 'Folder Credentials' to restrict access. Audit credential usage.
📊 Production Insight
A common mistake is storing passwords in plain text in job config. Always use credentials plugin. For database passwords, use 'Secret text' and bind as env var. Never echo secrets in console.
🎯 Key Takeaway
Use Jenkins credentials for all secrets. Bind them as environment variables. Never hardcode.
9. Chaining Jobs: Building Pipelines with Freestyle
Freestyle jobs can be chained to create a simple pipeline. Use 'Build after other projects are built' trigger or 'Build other projects' post-build action. For example: Job A (compile) triggers Job B (test) if successful, which triggers Job C (deploy) if successful.
To pass artifacts between jobs, use 'Archive the artifacts' in upstream job and 'Copy artifacts from another project' plugin in downstream job. Or use a shared filesystem (e.g., NFS).
Production: Use the 'Parameterized Trigger' plugin to pass parameters downstream. For complex pipelines, consider Pipeline plugin. Chaining freestyle jobs works for linear flows but becomes messy with branching.
Example: In Job A, post-build action 'Build other projects' > Job B. Check 'Trigger only if build is stable'. In Job B, add 'Copy artifacts from another project' step.
📊 Production Insight
Chained freestyle jobs are fragile. If a job fails, downstream jobs may not run. Use 'Build other projects' with 'Trigger even if unstable' carefully. For production, migrate to Pipeline for better error handling.
🎯 Key Takeaway
Chain freestyle jobs for simple linear pipelines. Use parameters and artifact copy. For complex flows, use Pipeline as Code.
10. Monitoring and Alerting for Freestyle Jobs
Monitor freestyle jobs via Jenkins UI, but for production, set up external monitoring. Use plugins: 'Build Monitor View', 'Green Balls' (optional), 'Email Extension' for detailed notifications. Configure email to send on failure or unstable. Use 'Slack Notification' plugin for real-time alerts.
Set up 'Disk Usage' plugin to monitor workspace and artifact sizes. Use 'Build Timeout' to prevent hung builds. Monitor queue length – if jobs pile up, scale agents.
Production: Use 'Monitoring' plugin to track Jenkins health (heap, CPU, disk). Set up alerts via email or Slack. Regularly check 'Manage Jenkins' > 'System Information' for errors.
📊 Production Insight
Don't rely on email alone – use Slack or PagerDuty for critical failures. Set up 'Build Blocker' plugin to prevent concurrent builds that conflict. Monitor agent availability.
🎯 Key Takeaway
Monitor builds with email, Slack, and plugins. Watch disk space and queue length. Automate alerts for failures.
11. When to Move from Freestyle to Pipeline
Freestyle jobs are great for simple tasks, but they have limitations: no version control of config, no parallel stages, complex logic requires plugins or messy scripts. When you need: - Pipeline as Code: Store CI config in SCM. - Parallel execution: Run tests in parallel. - Conditional logic: Different steps based on branch. - Resilience: Retry failed steps. - Input/approval gates: Manual approval before deploy.
Then migrate to Declarative or Scripted Pipeline. You can convert a freestyle job to a Pipeline by copying the build steps into a Jenkinsfile.
Production: Start with freestyle for quick wins, but plan migration to Pipeline as complexity grows. Use 'Multibranch Pipeline' for branches.
📊 Production Insight
I've seen teams stick with freestyle too long, ending up with 50 similar jobs. Pipeline as Code reduces duplication. Use the 'Pipeline: Multibranch' plugin to automatically create jobs per branch.
🎯 Key Takeaway
Freestyle for simple, linear workflows. Pipeline for complex, scalable CI/CD. Migrate when you need version control, parallelism, or conditional logic.
12. Production Best Practices for Freestyle Jobs
Use parameterized builds: Always parameterize branch, environment, etc.
Set build discarders: Keep last 10 builds, discard artifacts after 7 days.
Archive artifacts: Always archive build outputs for traceability.
Use credentials binding: Never hardcode secrets.
Keep build steps simple: Put complex logic in repo scripts.
Use 'Delete workspace before build': Avoid contamination.
Set timeouts: Prevent hung builds.
Monitor disk space: Use Disk Usage plugin.
Use webhooks over polling: Save resources.
Document job purpose: Use description field.
Restrict job configuration: Use 'Job Configuration' permission for admins only.
Use labels for agents: Run jobs on specific nodes if needed.
Production: Regularly audit jobs – remove unused ones. Use 'Job DSL' plugin to generate freestyle jobs from code if you need many similar jobs.
📊 Production Insight
One production tip: use 'Throttle Concurrent Builds' plugin to limit concurrent builds per node. Also, set 'Quiet period' to avoid multiple triggers from same commit.
🎯 Key Takeaway
Follow best practices: parameterize, discard old builds, archive artifacts, use credentials, keep steps simple, monitor resources.
● Production incidentPOST-MORTEMseverity: high
The Midnight Build Failure: A Disk Space Horror
Symptom
Jenkins master UI became unresponsive. All builds queued but never started. Error: 'java.io.IOException: No space left on device' in job console output.
Assumption
Team assumed a recent code change caused an infinite loop or massive log output. Some blamed a new developer's commit.
Root cause
Freestyle job archived artifacts without cleanup. Over months, artifact directory grew to fill the disk. Jenkins master could not create temp files for new builds.
Fix
1) Delete old artifacts: find $JENKINS_HOME/jobs//builds//archive -type f -mtime +30 -delete. 2) Configure 'Discard Old Builds' in job config: keep max 10 builds, discard artifacts after 7 days. 3) Add disk space monitoring alert in Jenkins (e.g., Monitoring plugin). 4) Restart Jenkins.
Key lesson
Always set build discarders on freestyle jobs.
Artifacts and logs accumulate silently.
Automate cleanup.
Monitor disk space proactively.
Production debug guideCommon failure patterns and how to fix them fast5 entries
Symptom · 01
Job hangs indefinitely with no output
→
Fix
Check if a shell command is waiting for input (e.g., missing 'yes' or 'nohup'). Add timeout to the job configuration: 'Build Environment' > 'Abort the build if it's stuck' > set timeout (e.g., 10 minutes). Also verify the agent is not overloaded.
Symptom · 02
Build fails with 'Permission denied' on workspace
→
Fix
Ensure the Jenkins user owns the workspace. Run 'sudo chown -R jenkins:jenkins /var/lib/jenkins/workspace' on the agent. For Docker agents, set user ID to match Jenkins user.
Symptom · 03
Job succeeds but artifacts are missing
→
Fix
Verify the 'Archive the artifacts' post-build action includes the correct path (relative to workspace). Use wildcards like '*/target/.jar'. Check if the build step runs in a subdirectory; artifacts must be archived from the correct base directory.
Symptom · 04
Environment variables not passed to shell steps
→
Fix
Freestyle jobs do not inherit system environment variables by default. Use 'Inject environment variables' plugin or set them explicitly in the build step: 'export VAR=value'. For sensitive data, use Jenkins Credentials Binding plugin.
Symptom · 05
Job fails intermittently with 'Connection refused' to external service
→
Fix
Add retry logic in the shell step: 'for i in 1 2 3; do curl -f http://service && break; sleep 5; done'. Also check network policies and service health before the job runs.
★ Jenkins Freestyle Job Debugging Cheat SheetQuick commands and fixes for the most common production issues.
Job stuck−
Immediate action
Abort the build and check console output for last line
Commands
ps aux | grep jenkins
Fix now
Add build timeout: 'Build Environment' > 'Abort the build if it's stuck' > set 10 min
Freestyle jobs are the simplest Jenkins project type
point-and-click configuration.
2
Use parameterized builds for reusability.
3
Always set build discarders to manage disk space.
4
Archive artifacts for traceability.
5
Use credentials binding for secrets, never hardcode.
6
Keep build steps simple; put complex logic in repo scripts.
7
Use webhooks over polling for efficiency.
8
Migrate to Pipeline jobs when you need version control, parallelism, or advanced features.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01JUNIOR
What is a Jenkins Freestyle job and when would you use it?
Q02JUNIOR
How do you pass parameters to a freestyle job?
Q03SENIOR
Explain the difference between 'Build periodically' and 'Poll SCM' trigg...
Q04SENIOR
How do you securely manage secrets in a freestyle job?
Q05SENIOR
What are the limitations of freestyle jobs compared to Pipeline jobs?
Q06SENIOR
Describe a production incident related to freestyle jobs and how you fix...
Q07SENIOR
How would you chain multiple freestyle jobs to create a deployment pipel...
Q08SENIOR
When should you migrate from freestyle to Pipeline as Code?
Q01 of 08JUNIOR
What is a Jenkins Freestyle job and when would you use it?
ANSWER
A Jenkins Freestyle job is a basic project type that lets you configure build steps, triggers, and post-build actions through a graphical interface without writing pipeline code. I use it for simple, linear tasks like running shell scripts, archiving artifacts, or triggering other jobs, especially when a team needs quick setup without learning Groovy syntax.
Q02 of 08JUNIOR
How do you pass parameters to a freestyle job?
ANSWER
In a freestyle job, you pass parameters by checking the "This project is parameterized" box in the job configuration, then adding parameter definitions like String, Choice, or Boolean. When you trigger the build, Jenkins prompts you to enter values, which are then accessible as environment variables, such as $PARAM_NAME in shell build steps.
Q03 of 08SENIOR
Explain the difference between 'Build periodically' and 'Poll SCM' triggers.
ANSWER
Build periodically triggers a job at a fixed schedule regardless of any code changes, while Poll SCM checks the repository at that schedule and only runs the job if there are new commits. Use build periodically for tasks like nightly cleanup or report generation, and Poll SCM to avoid unnecessary builds when the source code hasn't changed.
Q04 of 08SENIOR
How do you securely manage secrets in a freestyle job?
ANSWER
In a freestyle job, I avoid hardcoding secrets by using the "Bindings" section to inject credentials from the Jenkins credential store, which encrypts them at rest. For tools like Git or Docker, I configure the job to use pre-stored credentials via the "Add" button next to source code management or build environment options. This ensures secrets are never exposed in console logs or job configurations, and I restrict access to the credential IDs through Jenkins' folder-based authorization.
Q05 of 08SENIOR
What are the limitations of freestyle jobs compared to Pipeline jobs?
ANSWER
Freestyle jobs lack version control for job configuration, making it difficult to track changes or roll back, and they don't support complex logic like loops, conditionals, or parallel execution natively. They also cannot be easily reused or shared across projects since there's no way to define the job as code, and manual steps or plugins are often required for tasks that Pipeline jobs handle declaratively.
Q06 of 08SENIOR
Describe a production incident related to freestyle jobs and how you fixed it.
ANSWER
We had a freestyle job that would silently fail because it used shell scripts with exit codes not being checked, causing downstream deployments to proceed with corrupted artifacts. I fixed it by adding explicit exit code validation in each build step and wrapping the job in a pipeline script with try-catch logic to fail fast. I also implemented a post-build action to archive only if all steps succeeded and set up monitoring to alert on job status changes.
Q07 of 08SENIOR
How would you chain multiple freestyle jobs to create a deployment pipeline?
ANSWER
I would use the "Build after other projects are built" post-build action in each freestyle job to trigger the next job sequentially, passing artifacts via the "Archive the artifacts" and "Copy artifacts from another project" plugins. For more complex dependencies, I'd install the Parameterized Trigger plugin to pass build parameters between jobs, or use the Build Pipeline Plugin to visualize the entire chain. However, for production-grade pipelines, I'd recommend migrating to Jenkins Pipeline as Code (Declarative or Scripted) for better version control, error handling, and maintainability.
Q08 of 08SENIOR
When should you migrate from freestyle to Pipeline as Code?
ANSWER
Migrate when your build process grows beyond simple sequential steps, requires conditional logic, manual approvals, or parallel stages that freestyle jobs handle poorly with plugins. Pipeline as Code gives you version control, better error handling with try-catch blocks, and the ability to test and review CI/CD logic like application code. The tipping point is when you spend more time debugging freestyle job configurations than writing the actual pipeline logic.
01
What is a Jenkins Freestyle job and when would you use it?
JUNIOR
02
How do you pass parameters to a freestyle job?
JUNIOR
03
Explain the difference between 'Build periodically' and 'Poll SCM' triggers.
SENIOR
04
How do you securely manage secrets in a freestyle job?
SENIOR
05
What are the limitations of freestyle jobs compared to Pipeline jobs?
SENIOR
06
Describe a production incident related to freestyle jobs and how you fixed it.
SENIOR
07
How would you chain multiple freestyle jobs to create a deployment pipeline?
SENIOR
08
When should you migrate from freestyle to Pipeline as Code?
SENIOR
FAQ · 8 QUESTIONS
Frequently Asked Questions
01
Can I use a Jenkinsfile with a freestyle job?
No, freestyle jobs don't support Jenkinsfiles. You need to create a Pipeline job for that.
Was this helpful?
02
How do I run a freestyle job on a specific agent?
Use 'Restrict where this project can be run' in the General section and specify a label expression.
Was this helpful?
03
Can I trigger a freestyle job from a Git push?
Yes, use the 'GitHub hook trigger for GITScm polling' or 'Poll SCM' trigger with webhooks.
Was this helpful?
04
How do I copy artifacts from one freestyle job to another?
Use the 'Copy artifacts from another project' post-build action in the downstream job.
Was this helpful?
05
What is the maximum number of builds I should keep?
It depends on disk space, but typically keep last 10-20 builds. Use 'Discard old builds' to automate.
Was this helpful?
06
Can I run parallel steps in a freestyle job?
Not natively. You can use the 'Parallel Test Executor' plugin or split into multiple jobs.
Was this helpful?
07
How do I add a timeout to a freestyle job?
Use the 'Build Timeout' plugin or wrap your build step with the timeout command.
Was this helpful?
08
Is it possible to version control a freestyle job configuration?
Not directly. You can export the XML config and store it in SCM, but it's not as seamless as Pipeline.