Hands on DevOps Coaching provided on AWS and Azure Cloud platforms. please contact at devops.coaching@gmail.com for more info. You can also directly reach out to Coach AK at +1(469) 733-5248
The DevOps requirements in the IT market space is expected to grow by 35% by
2024. Getting a DevOps education now is a great investment into your future,
which will pay off very fast!
You are in the right place to kick start your career in DevOps. DevOps is one of the top and hot IT skills right now. Currently almost all the employers are struggling to get right
resources in their teams who can do the DevOps and automation work..You
could be that person by attending this coaching program.
Scenario #1(post build) - How to trigger a Jenkins job from another Free style Job?
1. Login to Jenkins instance. 2. Open your any existing freestyle build job. 3. Click on Configure
4. Go to post build action
5. Add post-build action --> click on Build other projects
6. Select job name(projects) that you want to trigger by typing the name of the job and also check trigger only if build is stable
7. Save the job. 8. Build job now, once the current job is built, it will trigger the next job immediately. Check the console output of the current job, you will see id would trigger second job
9. Go to the secondJob Check console output. You will see the second job got triggered by first build job.
Scenario #2 (pre-build) - How to trigger a Jenkins job from another Free style Job?
1. Open your freestyle build job. 2. Click on Configure
3. Click on Build triggers
4. Check build other projects are built.
Select source job name which will be built first and then once the build is stable, it will be trigger this job. And also check trigger only if build is stable.
5. Save the job.
6. Run the first job. once that job is successful, and then it will trigger this job.
Scenario #3 - How to trigger any Jenkins job from a pipeline Job:
A self-hosted GitHub runner is a machine (physical or virtual) that you set up and manage to run GitHub Actions workflows. GitHub Actions is a CI/CD (Continuous Integration/Continuous Deployment) and automation service provided by GitHub. It allows you to define workflows in your GitHub repositories to automate build, test, and deployment processes.
GitHub-hosted runner
Self-hosted runner
Larger runner
ephemeral self-hosted runners (on-demand)
GitHub-hosted runners:
These are runners provided by GitHub, and they are hosted on GitHub's infrastructure.
GitHub provides various virtual machine configurations for different operating systems and environments.
They are automatically scaled based on the demand, and you don't have to manage their infrastructure.
GitHub-hosted runners have time and resource limitations, and you may need to consider these limitations based on your project's needs.
Self-hosted runners:
A self-hosted runner differs from the default GitHub-hosted runners in that it runs on infrastructure that you control. Self-hosted runners can be physical, virtual, in a container, on-premises, or in a cloud.
GitHub-hosted large runners:
GitHub offers customers on GitHub Team and GitHub Enterprise Cloud plans a range of managed virtual machines with more RAM, CPU, and disk space. These runners are hosted by GitHub and have the runner application and other tools preinstalled.
Ephemeral self-hosted runners:
GitHub Actions now supports ephemeral (i.e. single job) self-hosted runners to make autoscaling your runners easier. After a job is run, ephemeral runners are automatically unregistered from the service, allowing you to do any required post-job management. Ephemeral runners are a good choice for self-managed environments where you need each job to run on a clean image.
GitHub Actions is a CICD platform to help you to automate tasks in software development lifecycle
It allows you to automate various tasks in your software development workflow by defining workflows using YAML files.
GitHub Actions are event-driven. i.e., when some event happens, you can trigger series of commands.
GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository.
GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.
GitHub Actions Workflow:
A workflow is a series of actions initiated once a triggering event occurs. For example, the triggering event can be some commit pushed to a GitHub repository, the creation of a pull request, or another workflow completed successfully. Event is the one which triggers the workflow.
Your workflow contains one or more jobs which can run in sequential order or in parallel. Each job will run inside its own virtual machine runner, or inside a container, and has one or more steps that either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.
Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.
Advantages of using GitHub Actions:
GitHub Actions offers several advantages for automating workflows in your software development process:
Integration with GitHub:
GitHub Actions is tightly integrated into the GitHub platform. This integration makes it easy to define, manage, and execute workflows directly within your repositories.
YAML-based Configuration:
Workflows are defined using YAML files, providing a simple and human-readable syntax. This makes it easy to understand, version, and share your workflow configurations.
Diverse Triggers:
GitHub Actions supports a variety of triggers for workflow execution, such as pushes, pull requests, issue comments, and scheduled events. This flexibility allows you to tailor workflows to your specific needs.
Parallel and Sequential Jobs:
Workflows can include multiple jobs that run in parallel or sequentially. This enables you to optimize build and test times by parallelizing tasks or organizing them in a specific order.
Reusable Actions:
GitHub Actions promotes code reuse through reusable actions. Actions are modular units of code that encapsulate a specific task and can be shared across different workflows and repositories
Supports a wide range of platforms and languages:
GitHub Actions supports a wide range of platforms and languages. This means that users can use the same automation tool for different projects and languages, which can simplify their workflows and reduce the need for multiple tools.
GitHub-hosted Runners:
GitHub provides virtual machines (runners) for executing workflows. These runners are pre-configured with various tools and environments, reducing the need for managing your own infrastructure.
Self-hosted Runners:
While GitHub provides hosted runners, you can also use self-hosted runners on your own infrastructure for greater control over the execution environment.
Community Actions:
GitHub Actions has a marketplace where you can find and share actions created by the community. This makes it easy to leverage existing solutions for common tasks in your workflows.
Secure:
GitHub Actions allows you to securely store and use secrets (e.g., API keys, access tokens) in your workflows, ensuring sensitive information is protected.
Sample GitHub Actions Workflow YAML for creating a WAR file using Maven
You will create this file .github/workflows/build.yaml inside GitHub Repo where your Java code is.
