Java4all

# Directory where plugin .hpi files will be stored
# File: plugins.yaml

# Define plugins with specific versions
# Example YAML file to track plugin versions

---
plugins:
  - name: git
    version: 5.1.0

Java4all

import jenkins.model.*
import hudson.PluginWrapper
import java.nio.file.*

def pluginDir = new File(Jenkins.instance.rootDir, "plugins")
def pluginList = [
  [name: "git", version: "5.2.1"],
  [name: "workflow-job", version: "2.40"]
]

Java4all

CloudBees CI (the enterprise version of Jenkins) uses Configuration as Code (CasC) bundles to manage plugins in a scalable, automated, and version-controlled way. Here's a detailed breakdown of how plugin management works within CasC bundles:

A. What Is a CasC Bundle?
A CasC bundle is a structured collection of YAML files that define the configuration of a CloudBees CI instance — including plugins, security, jobs, RBAC, and more. These bundles can be stored in Git and applied automatically to controllers via the CloudBees Operations Center.

B. Plugin Management via CasC

1. plugins.yaml File
This file lists all plugins that should be installed on a controller. It supports both CAP (CloudBees Assurance Program) plugins and custom plugins.

Java4all

1. What Is a Plugin in Jenkins?
A Jenkins plugin is a self-contained Java archive (.hpi or .jpi file) that extends Jenkins' core functionality. Plugins allow Jenkins to integrate with tools like Git, Docker, Maven, Slack, and even custom steps in your pipeline.
They’re the backbone of Jenkins’ flexibility — you can add build triggers, post-build actions, UI elements, pipeline steps, and more.

2. Where Are Plugins Stored?
Jenkins stores plugins in the following location on the controller (master) node:

$JENKINS_HOME/plugins/
Each plugin is stored as a .jpi or .hpi file.

Java4all

1.  Jenkins Plugin Manager CLI
The Jenkins Plugin Manager CLI (jenkins-plugin-manager) is officially recommended, modern, and robust:

 - Better dependency resolution.

 - Officially supported by Jenkins.

 - YAML-based plugin configuration.

2. Step-by-step Automation Guide:

Java4all

#!/usr/bin/env bash

FILENAME=${1}
# expected to be defined in the environment
#  - AZURE_STORAGE_ACCOUNT
#  - AZURE_CONTAINER_NAME
#  - AZURE_ACCESS_KEY

# inspired by

Java4all

# Working with a [System.IO.FileInfo] Object
## Get file object into variable
PS C:\DATA> $file = Get-ChildItem C:\DATA\test.xls

## Full path name
PS C:\DATA> $file.FullName
C:\DATA\test.xls

## Filename including extension
PS C:\DATA> $file.Name

Java4all

Amazon changed the install in Linux 2. One no-longer using 'yum' See: https://aws.amazon.com/amazon-linux-2/release-notes/

Docker CE Install - AWS Linux 2 AMI

sudo amazon-linux-extras install docker
sudo service docker start
sudo usermod -a -G docker ec2-user

Java4all

#!/usr/bin/env bash

###
# The script uses CFN to provision a Target Group in the app-dev ALB, and creates
# an instance behind that target group, after which it  attaches two host-header
# based rules to the HTTP/HTTPS listeners which target the newly created target group.
# After the stack is up, it installs the relevant Strigo app, ssc and job-worker builds
# on it for the relevant branch.
#
# NOTE: AWS_DEFAULT_REGION, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY must be set prior to running this.

Java4all

#!/usr/bin/env bash
URL="http://localhost:15672/cli/rabbitmqadmin"

VHOST="<>"
USER="<>"
PWD="<>"

QUEUE="<>"
FAILED_QUEUE="<>"