Demo showing how to audit Jenkins, add a multibranch pipeline, add a secret binding, and regenerate GitHub Actions workflow snippets with redacted secrets
In this lesson we update the Jenkins instance, add a Multi-branch Pipeline, create a secret binding in an existing job, and re-run the audit to see how the audit summary and generated artifacts change.What you’ll see in this demo:
Creating a Multi-branch Pipeline that discovers Jenkinsfiles in multiple branches.
Indexing output from Jenkins showing discovered branches.
Adding a secret via the job’s Environment → Bindings and using it in a shell step.
Re-running the gh actions-importer audit jenkins command and inspecting the updated audit summary and generated GitHub Actions workflow snippets.
Initial state: existing Jenkins jobs and previous audit
There were four Jenkins jobs discovered by the previous audit. One job was in a pending state (likely an agent issue); it was cancelled so it wouldn’t interfere with the demo.For reference, here is the trimmed audit summary from the previous run:
We created a new GitHub repo jenkins-demo-org/demo-repo containing two branches: main and uat. Each branch contains a Jenkinsfile — main includes a single stage, while uat contains two stages. To add the multi-branch job in Jenkins, choose New Item → Multi-branch Pipeline and point the Branch Source to the GitHub repository.
The demo repository in GitHub:
Example Jenkinsfile (used in both branches, with uat containing Stage-2):
In the Multi-branch Pipeline configuration we pointed Branch Source to the GitHub repository and validated the connection. This repo is public, so no Jenkins credentials were required when validating the branch source.
We left other settings at defaults and saved the job. Jenkins scanned the repository and indexed both branches, reporting that each branch contained a Jenkinsfile and was scheduled for indexing:
Indexing console output:
Examining jenkins-demo-org/demo-repoChecking branches...Getting remote branches...Checking branch main 'Jenkinsfile' found Met criteriaScheduled build for branch: mainChecking branch uat 'Jenkinsfile' found Met criteriaScheduled build for branch: uat2 branches were processedFinished examining jenkins-demo-org/demo-repo[Thu May 22 09:22:59 UTC 2025] Finished branch indexing. Indexing took 2.2 secFinished: SUCCESS
After indexing, the main branch showed a successful build:
Next, we switched to an existing job (Generate ASCII Artwork) and added a secret via Configure → Environment → Bindings. We added a Secret text binding named m_username and selected an existing stored credential (mongo-db-password) for the demo.
Bindings configured in the job:
We used that variable inside a shell build step. The original demo script had syntax issues; below is an improved and safer version suitable for a shell build step:
#!/bin/bash# Build a message by invoking ADVICESLIP APIcurl -s https://api.adviceslip.com/advice > advice.jsoncat advice.json# Test to make sure the advice message has more than 5 words.jq -r .slip.advice < advice.json > advice.messageif [ $(wc -w < advice.message) -gt 5 ]; then echo "Advice has more than 5 words"else echo "Advice - $(cat advice.message) has 5 or fewer words"fi# Deploy (example)echo "$m_username"sudo apt-get update && sudo apt-get install -y cowsayecho "$PATH"export PATH="$PATH:/usr/games:/usr/local/games"
Notes:
Use jq to extract structured JSON fields reliably.
Avoid printing secrets to logs in production — the example echoes the secret only for demonstration.
After saving the new multi-branch job and the updated job with a secret binding, we re-ran the audit to refresh the report and capture the new job and secret binding.Run the audit:
Generated GitHub Actions workflow and secret mapping
The import tool redacted secrets and generated workflow YAML for the Jenkins jobs it can map. It detected the m_username secret and mapped it to a repository/organization-level secret in the generated workflow. You (or a repo administrator) must create that secret in GitHub (repo/org/environment level) so the workflow can use it at runtime.Example generated workflow snippet (secrets must be created in GitHub prior to running the workflow):
name: Generate_ASCII_Artworkon: workflow_dispatch:env: m_username: "${{ secrets.MONGO_DB_PASSWORD_M_USERNAME }}"jobs: build: runs-on: - ubuntu-latest steps: - name: checkout uses: actions/checkout@v4.1.0 - name: run command shell: bash run: | # Build a message by invoking ADVICESLIP API curl -s https://api.adviceslip.com/advice > advice.json cat advice.json # Test to make sure the advice message has more than 5 words. jq -r .slip.advice < advice.json > advice.message if [ $(wc -w < advice.message) -gt 5 ]; then echo "Advice has more than 5 words" else echo "Advice - $(cat advice.message) has 5 or fewer words" fi # Deploy echo "$m_username" sudo apt-get update && sudo apt-get install -y cowsay
Important: The tool maps many Jenkins credential types to appropriate GitHub Actions equivalents and creates references in the generated workflows, but it does not create the repository/org secrets for you — you must create those secrets manually in GitHub.
The audit tool maps many Jenkins credential types to GitHub Actions equivalents, but referenced secrets must be created in GitHub (repo/org/environment level) before the workflow runs.
That’s it for this lesson — the updated audit summary and generated artifacts reflect the newly added multi-branch pipeline and the secret binding added to the existing job.
