Monday, 27 April 2026

Understanding github.event.inputs in GitHub Actions

 When working with GitHub Actions, you often want your workflows to be flexible rather than hard-coded. One powerful way to achieve this is by using custom inputs with the workflow_dispatch event.

The github.event.inputs context allows you to access values that are provided manually at the time of triggering a workflow. This makes your automation dynamic and reusable across different scenarios.


🔹 What is workflow_dispatch?

workflow_dispatch is a trigger that lets you manually run a workflow from the GitHub UI. While triggering it, you can pass custom input values, which can then be used inside the workflow.


🔹 Why use github.event.inputs?

Instead of hardcoding values like environment names or version numbers, you can:

  • Provide inputs at runtime
  • Make workflows reusable
  • Reduce duplication
  • Improve control over deployments and scripts

🔹 Example 1: Basic Input Usage

This example demonstrates how to define a simple input and print it during workflow execution.

on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'

jobs:
print-log:
runs-on: ubuntu-latest
steps:
- name: Print the input
run: echo "The log level is ${{ github.event.inputs.logLevel }}"

✅ What happens here?

  • A user manually triggers the workflow
  • They can enter a value for logLevel (or use the default)
  • The workflow prints the selected value

🔹 Example 2: Advanced Inputs with Choices

You can also define more structured inputs, such as dropdowns and optional parameters.

1. Defining Inputs

on:
workflow_dispatch:
inputs:
environment:
description: 'Target environment'
required: true
default: 'development'
type: choice
options:
- development
- staging
- production
db_patch_version:
description: 'Version number for the patch'
required: false
type: string

2. Accessing Inputs in Workflow

jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Run Migration
run: |
echo "Deploying to: ${{ github.event.inputs.environment }}"
echo "Applying patch: ${{ github.event.inputs.db_patch_version }}"

✅ What happens here?

  • The user selects an environment from a dropdown
  • Optionally provides a database patch version
  • The workflow uses these inputs during execution

🔹 Key Takeaways

  • github.event.inputs is used to access user-provided values in manually triggered workflows
  • Inputs must be defined under on: workflow_dispatch
  • Values are accessed using:

    ${{ github.event.inputs.<input_name> }}
  • Supports multiple types like:
    • string
    • choice (dropdown)
    • boolean (in newer versions)

JFrog Artifactory OSS Installation Guide

CentOS 9 + PostgreSQL 17

This guide provides a structured workflow to install JFrog Artifactory OSS using PostgreSQL as an external database. This setup is preferred for production-like environments because it offers better performance and reliability than the default embedded database.


1. System Preparation

Before installing the application, ensure the host environment meets the software requirements.

  • Update System: Refresh repository metadata and installed packages.

    Bash
    yum update -y
    
  • Java Runtime: Artifactory is a Java-based application and requires JDK 21.

    Bash
    dnf install -y java-21-openjdk java-21-openjdk-devel
    java -version

2. External Database Setup (PostgreSQL 17)

Using an external database ensures that your artifact metadata is stored robustly.

  • Initialization: Here we use a postgres database to store the metadata. After installing the PostgreSQL server, initialize the data directory and enable the service.

    Bash
    /usr/pgsql-17/bin/postgresql-17-setup initdb
    systemctl enable postgresql-17 --now
    
  • Access Control: Edit /var/lib/pgsql/17/data/pg_hba.conf to allow Artifactory to connect. Change the local connection method from ident or peer to md5 (or trust for initial testing).

  • Database Provisioning: Create a dedicated database and user for Artifactory.

    SQL
    CREATE USER artifactory WITH PASSWORD 'your_password';
    CREATE DATABASE artifactory WITH OWNER artifactory;
    GRANT ALL PRIVILEGES ON DATABASE artifactory TO artifactory;

3. JFrog Artifactory Installation

  • Repository Configuration: Download the official JFrog RPM repository definition and move it to the system’s repo directory.

    Bash
    curl -L https://bintray.com/jfrog/artifactory-rpms/rpm -o jfrog-artifactory-rpms.repo
    mv jfrog-artifactory-rpms.repo /etc/yum.repos.d/
    
  • Package Installation: Install the Open Source (OSS) version.

    Bash
    yum install jfrog-artifactory-oss -y

4. Security & Connectivity Configuration

  • Encryption (Master Key): Artifactory requires a unique 16-bit hex key to encrypt sensitive system data (like database passwords).

    Bash
    mkdir -p $JFROG_HOME/artifactory/var/etc/security
    openssl rand -hex 16 > $JFROG_HOME/artifactory/var/etc/security/master.key
    chown -R artifactory: /opt/jfrog/artifactory/var/etc/security
    
  • Database Linking: Configure the system.yaml file to tell Artifactory to use PostgreSQL instead of the default Derby database.The system.yaml file is the primary configuration file for all Artifactory services. You must explicitly define the connection string to the external database.

    YAML
    shared:
      database:
        type: postgresql
        driver: org.postgresql.Driver
        url: "jdbc:postgresql://localhost:5432/artifactory"
        username: artifactory
        password: your_password
    

5. Service Launch & Verification

  • Network Access: Disable the firewall or open ports 8081 (Artifact data) and 8082 (UI/Router).

    Bash
    systemctl stop firewalld && systemctl disable firewalld
    
  • Startup: Start the Artifactory service and monitor the console logs for a "Ready" state.

    Bash
    systemctl start artifactory.service
    tail -f /opt/jfrog/artifactory/var/log/console.log
    
  • Dashboard Access: Navigate to http://<SERVER_IP>:8082.

    • Login: admin

    • Password: password (You will be prompted to change this immediately).

Wednesday, 24 December 2025

Ansible 31. any_errors_fatal and a comparison


By default, if a task fails on one server (Host A), Ansible stops working on that server but continues trying to finish the task on all your other servers (Host B, Host C, etc.).

When you set any_errors_fatal: true, you are telling Ansible: "If even one server fails this task, stop everything immediately on all servers."

Why use it?

It is used for "all-or-nothing" scenarios where you cannot afford to have your environment in a mixed state.

  • Database Migrations: If the migration fails on one node, you don't want the others to keep going and potentially corrupt the cluster.

  • Load Balancers: If you are taking servers out of a rotation and one fails to leave the pool, you might want to stop the whole process before you start shutting down services.


Where can you put it?

You can apply this at different levels of your code:


LevelScope
Play LevelAffects every task in that specific play.
Block LevelAffects only the group of tasks inside that specific block.
Task LevelNot typically supported directly on a single task (usually used at play/block level).

Comparison of Scope Keywords

It is easy to get confused because several error-handling keywords can be used at the task level, but any_errors_fatal is an exception.


KeywordTask Level?Block Level?Play Level?
ignore_errorsYesYesYes
failed_whenYesNoNo
any_errors_fatalNoYesYes
ignore_unreachableYesYesYes

Building a Safer PostgreSQL CI/CD Pipeline with GitHub Actions: Dev → PR Review → Test Promotion

In my previous post, we explored a simple push-to-main deployment strategy . While functional, that model is not considered an industry best...