GitHub Workflows 
Think of a workflow as a set of instructions you give to GitHub.
Whenever something happens in your project (like you push code), GitHub will automatically follow those instructions.

Example:

• You push code, then GitHub runs tests, then if tests pass, it deploys your app.
• So, Workflows save you from doing repetitive tasks manually (like testing or deploying every time). You just set it up once, and GitHub takes care of it.

GitHub Workflows are part of GitHub Actions that help you automate tasks like building, testing, or deploying your code right from your GitHub repository.
They are flexible and customizable, so you can design automation that matches exactly what your project needs.

A workflow is like an automation script that tells GitHub what tasks to run for your project.

• It is made up of one or more jobs (steps that run in order).
• Workflows are written in YAML files and stored inside the .github/workflows/ folder of your repository.
• They can start automatically when something happens — like:
  • You push code
  • You open a pull request
  • Or at a scheduled time
• You can even run them manually when needed.

Key Parts of a GitHub Workflow

1. Events : These are the triggers that start your workflow.
   • Example: when you push code, create a pull request, or run on a schedule.
2. Jobs : A job is a collection of steps that run on a GitHub runner (a virtual machine).
   • By default, multiple jobs can run at the same time (parallel).
   • You can also set them to run one after another (sequential) if needed.
3. Steps : These are the individual tasks inside a job.
   • A step can be a command (like npm install)
   • Or an action (a reusable piece of code provided by GitHub or the community).
4. Runners : A runner is the computer (server) where your workflow actually runs.
   • GitHub gives you free hosted runners (already set up) with different operating systems like Ubuntu, Windows, and macOS.
   • If you want more control, you can also use your own machine as a self-hosted runner.
   • Think of runners as the worker machines that carry out the jobs you define in your workflow.