Madanswer Technologies Interview Questions Data|Agile|DevOPs|Python - Recent questions and answers in GitHub

Answered: How is Git different from SVN?

Tue, 22 Aug 2023 20:54:14 +0000

The differences between Git and SVN are one of the notable entries among the best Git interview questions. First of all, Git does not have adequate functionality for managing excessively large files or frequently fluctuating binary files. On the other hand, SVN can manage multiple projects in the same repository.

The second point of difference is in the fact that Git lacks support for commits across multiple branches or tags. On the contrary, SVN or Subversion supports the creation of folders irrespective of the location in the repository layout. Modifications in Gits are impossible. However, Subversion provides flexibility to committers for treating a tag as a branch and creating multiple revisions in a tag root. However, the distributed Git is better than the centralized SVN.

Answered: What is a bare repository?

Tue, 22 Aug 2023 20:53:32 +0000

Candidates can also come across this entry among top Git interview questions as a follow-up question. A bare repository contains information regarding version control. The bare repository does not contain any working files or the special.git sub-directory. On the contrary, the bare repository contains all information of the .git subdirectory in the main directory directly. The working directory contains the working tree, i.e., verified copies of project files and .git subdirectory with all Git related revision history for your repository.

Answered: Explain Github Workflow?

Tue, 22 Aug 2023 20:51:21 +0000

Git provides three key areas that are uniquely designed, to give developers lots of control over workflow:

A working directory, which contains all the current states of files. Numerous developers can access the directory when they are logged in, so collaboration is extremely easy.
Staging area, which indexes everything for the next commit, and any files that have been added or edited since the previous save.
Git repository is a dedicated space where new commits are added. A Git repository maintains all the metadata, the files, and a dedicated database that tracks versions of the project.

With proper importance given to speed, data integrity, and excellent support for distributed, non-linear workflows, GitHub provides excellent standards for remote digital teams. In addition, Git is convenient for working offline or without a VPN (a virtual private network), making it easy for the developers to work on the move and stay productive at will. For small & medium enterprises that are involved in building sites rapidly and prototypes for their customers, GitHub is the most efficient, safe, and seamless way to get projects reviewed, approved, and signed off or on. GitHub provides the most cost-effective module in any business.

Answered: What Is a Staging Environment?

Tue, 22 Aug 2023 20:50:29 +0000

This is a process through which, we request Git, to put files into a commit? This is where the staging environment or index comes in handy. When we make changes to the repo, Git notices that a file has changed but will not do anything with it (like adding it in a commit). To add a file to a commit, we need to add it to the staging environment. To do this, we can use the Git add command. Once we have used the Git, add the command to add all the files we want to the staging environment, we can then request Git to package them into a commit using the Git commit command.

Answered: How To Upload Files To Github?

Tue, 22 Aug 2023 20:49:31 +0000

Following are the step required for uploading files:

Navigate to the main page of the GitHub repository.
Under your repository name, click Upload files.
Drag and drop the file or folder you would like to upload to your repository onto the file tree.
At the bottom of the page, type a short, meaningful commit message that describes the change you made to the file.

Answered: What is origin in Git?

Tue, 22 Aug 2023 04:12:57 +0000

Origin refers to the remote repository that a project was originally cloned from and is used instead of the original repository’s URL. This allows for easier referencing.

Answered: What is cherry-pick in Git?

Tue, 22 Aug 2023 04:12:07 +0000

Git cherry-pick is a command that allows the picking of arbitrary Git commits by reference and adding them to the HEAD. Cherry-picking is the process of picking a commit from one branch and applying it to another. It helps in undoing changes.

Answered: What are the advantages of Git over SVN?

Tue, 22 Aug 2023 04:11:25 +0000

What are the advantages of Git over SVN?

Since Git is an open source version control system it lets us run multiple versions of our project so that it shows the changes that are made to the code over time and if needed we can keep track of the changes that we have made. This means that a large number of developers can make their own changes and upload those changes so that the changes can be attributed to the particular developers.

Answered: What language is used in GIT?

Tue, 22 Aug 2023 04:10:33 +0000

C is the programming language that is used for creating Git which ensures that the overheads are reduced.

Answered: What is gist programming?

Tue, 22 Aug 2023 04:09:53 +0000

GitHub provides a hosting service that facilitates a web-based Git repository. It includes all the functionality of Git with additional features added in. The gist is an additional attribute added to GitHub, which facilitates the sharing of code snippets, notes, to do lists, and more. We can save our Gists as secret or public in the repository.

Answered: Is it possible in Git to merge a branch into the master? How can you find the same?

Tue, 22 Aug 2023 04:07:46 +0000

Yes, it is possible and the users can easily keep the pace up with the same anytime. The users can directly check the list under the branch section to know more about this.

Answered: How it is possible for a developer to simply update the remote references related to the different objects?

Tue, 22 Aug 2023 04:07:16 +0000

This is possible through the Git PUSH. In fact, it is actually the prime function of the same.

Answered: Can We Change Our Github Username?

Tue, 22 Aug 2023 04:06:42 +0000

We can change our GitHub account name at any time. For this, we need to click the profile picture > Settings > Account Settings > Change Username. Links to the repositories will redirect to the new URLs, but they should be updated on all other sites because someone who chooses the abandoned username can override the links.

Answered: What Is A Branch On Github?

Tue, 22 Aug 2023 04:05:49 +0000

Branch in Git means a lightweight movable pointer to one of these commits. The default branch name in Git is the master. As we initially make commits, we are given a master branch that points to the last commit being made. Every time we commit, it moves forward automatically.

Answered: What Is A Github Fork?

Tue, 22 Aug 2023 04:04:18 +0000

Fork is a copy of a repository. Forking a repository allows us to freely experiment with the changes without affecting the original project. Most commonly, forks are used to propose changes to someone else’s project or to use someone else’s project as a starting point of our own idea.

Answered: How Can We Create A Branch In Github?

Tue, 22 Aug 2023 04:03:39 +0000

GitHub has a simple UI for creating branches. Once opened the branch drop-down and it prompts “Find or create a branch.” We need to Type the name of your new branch, then click the “create” button that appears. For retrieving the new branch from GitHub, we can use the standard Git fetch command.

Answered: How To Use Github?

Tue, 22 Aug 2023 04:03:01 +0000

The use of GitHub can be explained in the following steps:

Install git and create a GitHub account.
Create a local git repository.
Add a new file to the repo.
Add a file to the staging environment.
Create a commit.
Create a new branch.

Answered: What Is Repo?

Tue, 22 Aug 2023 04:02:25 +0000

GitHub users shorten this to “repo.” It can be local to a folder on the computer, or it can be a storage space on GitHub or another online host. We can keep code files, text files, image files; our name it, inside a repository.

Answered: What Is Github Handle?

Tue, 22 Aug 2023 04:01:29 +0000

GitHub handle is the username, which is displayed, on the top right corner in GitHub. This is the one we use to log in to GitHub when we enter the site and commit to HTTPS and the one that appears in the URLs of our GitHub repositories.

Answered: Is Github Open Source Software?

Tue, 22 Aug 2023 04:00:36 +0000

GitHub is not open-source software because they have a commercial offer based known as “GitHub for Enterprise.” Nevertheless, anyone can apply their ideas just like open-source software on GitHub look-alike, known as GitLab which is a ruby application with its source code here.

Answered: What is project_card webhook trigger in github ?

Thu, 03 Aug 2023 02:34:57 +0000

`project_card`

Webhook event payload	Activity types	`GITHUB_SHA`	`GITHUB_REF`
`project_card`	- `created` - `moved` - `converted` to an issue - `edited` - `deleted`	Last commit on default branch	Default branch

Note: More than one activity type triggers this event. For information about each activity type, see "Webhook events and payloads."

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Note: This event only occurs for projects owned by the workflow's repository, not for organization-owned or user-owned projects or for projects owned by another repository.

Note: This event only occurs for projects (classic).

Runs your workflow when a card on a project board is created or modified. For activity related to project boards or columns in a project board

Answered: Explain about the project webhook trigger in Github actions?

Thu, 03 Aug 2023 02:32:20 +0000

`project`

Webhook event payload	Activity types	`GITHUB_SHA`	`GITHUB_REF`
`project`	- `created` - `closed` - `reopened` - `edited` - `deleted`	Last commit on default branch	Default branch

Note: More than one activity type triggers this event. The edited activity type refers to when a project board, not a column or card on the project board, is edited. For information about each activity type.

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Note: This event only occurs for projects owned by the workflow's repository, not for organization-owned or user-owned projects or for projects owned by another repository.

Note: This event only occurs for projects (classic).

Runs your workflow when a project board is created or modified. For activity related to cards or columns in a project board.

For example, you can run a workflow when a project has been created or deleted.

on:
  project:
    types: [created, deleted]

Answered: Explain about the page_build webhook trigger event in Github?

Thu, 03 Aug 2023 02:30:56 +0000

Webhook event payload	Activity types	`GITHUB_SHA`	`GITHUB_REF`
`page_build`	Not applicable	Last commit on default branch	Not applicable

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Runs your workflow when someone pushes to a branch that is the publishing source for GitHub Pages, if GitHub Pages is enabled for the repository.

For example, you can run a workflow when the page_build event occurs.

on:
  page_build

Answered: What is milestone webhook trigger event?

Thu, 03 Aug 2023 02:26:33 +0000

`milestone`

Webhook event payload	Activity types	`GITHUB_SHA`	`GITHUB_REF`
`milestone`	- `created` - `closed` - `opened` - `edited` - `deleted`	Last commit on default branch	Default branch

Note: More than one activity type triggers this event. For information about each activity type

Runs your workflow when a milestone in the workflow's repository is created or modified. For more information about milestones. If you want to run your workflow when an issue is added to or removed from a milestone, use the milestoned or demilestoned activity types for the issues event instead.

For example, you can run a workflow when a milestone has been opened or deleted.

on:
  milestone:
    types: [opened, deleted]

Answered: What is merge_group Webhook event type in GitHub?

Thu, 03 Aug 2023 02:25:08 +0000

`merge_group`

Webhook event payload	Activity types	`GITHUB_SHA`	`GITHUB_REF`
`merge_group`	`checks_requested`	SHA of the merge group	Ref of the merge group

Note: More than one activity type triggers this event. Although only the checks_requested activity type is supported, specifying the activity type will keep your workflow specific if more activity types are added in the future.

Runs your workflow when a pull request is added to a merge queue, which adds the pull request to a merge group.

For example, you can run a workflow when the checks_requested activity has occurred.

on:
  merge_group:
    types: [checks_requested]

Answered: Explain about the label webhook event in Github?

Thu, 03 Aug 2023 02:23:39 +0000

Webhook event payload	Activity types	`GITHUB_SHA`	`GITHUB_REF`
`label`	- `created` - `edited` - `deleted`	Last commit on default branch	Default branch

Note: More than one activity type triggers this event. For information about each activity type. By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the types keyword.

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Runs your workflow when a label in your workflow's repository is created or modified. For more information about labels.If you want to run your workflow when a label is added to or removed from an issue, pull request, or discussion, use the labeled or unlabeled activity types for the issues, pull_request, pull_request_target, or discussion events instead.

For example, you can run a workflow when a label has been created or deleted.

on:
  label:
    types: [created, deleted]

Answered: Explain about the issues trigger event in github actions?

Thu, 03 Aug 2023 02:21:55 +0000

Webhook event payload	Activity types	`GITHUB_SHA`	`GITHUB_REF`
`issues`	- `opened` - `edited` - `deleted` - `transferred` - `pinned` - `unpinned` - `closed` - `reopened` - `assigned` - `unassigned` - `labeled` - `unlabeled` - `locked` - `unlocked` - `milestoned` - `demilestoned`	Last commit on default branch	Default branch

Note: More than one activity type triggers this event. For information about each activity type, By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the types keyword. For more information.

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Runs your workflow when an issue in the workflow's repository is created or modified. For activity related to comments in an issue, use the issue_comment event.

For example, you can run a workflow when an issue has been opened, edited, or milestoned.

on:
  issues:
    types: [opened, edited, milestoned]

Answered: Event trigger issue_comment on issues only or pull requests only in GithubActions?

Thu, 03 Aug 2023 02:19:39 +0000

The issue_comment event occurs for comments on both issues and pull requests. You can use the github.event.issue.pull_request property in a conditional to take different action depending on whether the triggering object was an issue or pull request.

For example, this workflow will run the pr_commented job only if the issue_comment event originated from a pull request. It will run the issue_commented job only if the issue_comment event originated from an issue.

on: issue_comment

jobs:
  pr_commented:
    # This job only runs for pull request comments
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on PR $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

  issue_commented:
    # This job only runs for issue comments
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on issue $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

Answered: Explain about events that trigger workflows in gitHub?

Thu, 03 Aug 2023 02:18:22 +0000

You can configure your workflows to run when specific activity on GitHub happens, at a scheduled time, or when an event outside of GitHub occurs.

Workflow triggers are events that cause a workflow to run. Some events have multiple activity types. For these events, you can specify which activity types will trigger a workflow run.

branch_protection_rule

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
branch_protection_rule	- created - edited - deleted	Last commit on default branch	Default branch

Runs your workflow when branch protection rules in the workflow repository are changed. For more information about branch protection rules, see "About protected branches." For information about the branch protection rule APIs

For example, you can run a workflow when a branch protection rule has been created or deleted:

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
check_run	- created - rerequested - completed - requested_action	Last commit on default branch	Default branch

Runs your workflow when activity related to a check run occurs. A check run is an individual test that is part of a check suite.

For example, you can run a workflow when a check run has been rerequested or completed.

on:
  check_run:
    types: [rerequested, completed]

check_suite

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
check_suite	- completed	Last commit on default branch	Default branch

Runs your workflow when check suite activity occurs. A check suite is a collection of the check runs created for a specific commit. Check suites summarize the status and conclusion of the check runs that are in the suite.

For example, you can run a workflow when a check suite has been completed.

on:
  check_suite:
    types: [completed]

create

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
create	Not applicable	Last commit on the created branch or tag	Branch or tag created

Note: An event will not be created when you create more than three tags at once.

Runs your workflow when someone creates a Git reference (Git branch or tag) in the workflow's repository.

For example, you can run a workflow when the create event occurs.

on:
  create

delete

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
delete	Not applicable	Last commit on default branch	Default branch

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Note: An event will not be created when you delete more than three tags at once.

Runs your workflow when someone deletes a Git reference (Git branch or tag) in the workflow's repository.

deployment

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
deployment	Not applicable	Commit to be deployed	Branch or tag to be deployed (empty if created with a commit SHA)

Runs your workflow when someone creates a deployment in the workflow's repository. Deployments created with a commit SHA may not have a Git ref. For information about the APIs to create a deployment.

deployment_status

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
deployment_status	Not applicable	Commit to be deployed	Branch or tag to be deployed (empty if commit)

Note: When a deployment status's state is set to inactive, a workflow run will not be triggered.

Runs your workflow when a third party provides a deployment status. Deployments created with a commit SHA may not have a Git ref.

discussion

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
discussion	- created - edited - deleted - transferred - pinned - unpinned - labeled - unlabeled - locked - unlocked - category_changed - answered - unanswered	Last commit on default branch	Default branch

Runs your workflow when a discussion in the workflow's repository is created or modified. For activity related to comments on a discussion.

discussion_comment

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
discussion_comment	- created - edited - deleted	Last commit on default branch	Default branch

Runs your workflow when a comment on a discussion in the workflow's repository is created or modified.

fork

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
fork	Not applicable	Last commit on default branch	Default branch

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Runs your workflow when someone forks a repository.

gollum

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
gollum	Not applicable	Last commit on default branch	Default branch

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Runs your workflow when someone creates or updates a Wiki page.

issue_comment

Webhook event payload	Activity types	GITHUB_SHA	GITHUB_REF
issue_comment	- created - edited - deleted	Last commit on default branch	Default branch

Note: More than one activity type triggers this event. For information about each activity type, see "Webhook events and payloads." By default, all activity types trigger workflows that run on this event. You can limit your workflow runs to specific activity types using the types keyword. For more information, see "Workflow syntax for GitHub Actions."

Note: This event will only trigger a workflow run if the workflow file is on the default branch.

Runs your workflow when an issue or pull request comment is created, edited, or deleted. For information about the issue comment APIs

Answered: How can re-run a workflows and jobs with reusable workflows in github?

Thu, 03 Aug 2023 02:11:39 +0000

Reusable workflows from public repositories can be referenced using a SHA, a release tag, or a branch name. For more information, see "Reusing workflows."

When you re-run a workflow that uses a reusable workflow and the reference is not a SHA, there are some behaviors to be aware of:

Re-running all jobs in a workflow will use the reusable workflow from the specified reference. For more information about re-running all jobs in a workflow.
Re-running failed jobs or a specific job in a workflow will use the reusable workflow from the same commit SHA of the first attempt.

Answered: For Monitoring which workflows are being used in github?

Thu, 03 Aug 2023 02:10:09 +0000

You can use the GitHub REST API to monitor how reusable workflows are being used. The prepared_workflow_job audit log action is triggered when a workflow job is started. Included in the data recorded are:

repo - the organization/repository where the workflow job is located. For a job that calls another workflow, this is the organization/repository of the caller workflow.
@timestamp - the date and time that the job was started, in Unix epoch format.
job_name - the name of the job that was run.
calling_workflow_refs - an array of file paths for all the caller workflows involved in this workflow job. The items in the array are in the reverse order that they were called in. For example, in a chain of workflows A > B > C, when viewing the logs for a job in workflow C, the array would be ["octo-org/octo-repo/.github/workflows/B.yml", "octo-org/octo-repo/.github/workflows/A.yml"].
calling_workflow_shas - an array of SHAs for all the caller workflows involved in this workflow job. The array contains the same number of items, in the same order, as the calling_workflow_refs array.
job_workflow_ref - the workflow file that was used, in the form {owner}/{repo}/{path}/{filename}@{ref}. For a job that calls another workflow, this identifies the called workflow.

Answered: How to use outputs from a reusable workflow in github?

Thu, 03 Aug 2023 02:08:55 +0000

A reusable workflow may generate data that you want to use in the caller workflow. To use these outputs, you must specify them as the outputs of the reusable workflow.

If a reusable workflow that sets an output is executed with a matrix strategy, the output will be the output set by the last successful completing reusable workflow of the matrix which actually sets a value. That means if the last successful completing reusable workflow sets an empty string for its output, and the second last successful completing reusable workflow sets an actual value for its output, the output will contain the value of the second last completing reusable workflow.

The following reusable workflow has a single job containing two steps. In each of these steps we set a single word as the output: "hello" and "world." In the outputs section of the job, we map these step outputs to job outputs called: output1 and output2. In the on.workflow_call.outputs section we then define two outputs for the workflow itself, one called firstword which we map to output1, and one called secondword which we map to output2.

YAML

name: Reusable workflow

on:
  workflow_call:
    # Map the workflow outputs to job outputs
    outputs:
      firstword:
        description: "The first output string"
        value: ${{ jobs.example_job.outputs.output1 }}
      secondword:
        description: "The second output string"
        value: ${{ jobs.example_job.outputs.output2 }}

jobs:
  example_job:
    name: Generate output
    runs-on: ubuntu-latest
    # Map the job outputs to step outputs
    outputs:
      output1: ${{ steps.step1.outputs.firstword }}
      output2: ${{ steps.step2.outputs.secondword }}
    steps:
      - id: step1
        run: echo "firstword=hello" >> $GITHUB_OUTPUT
      - id: step2
        run: echo "secondword=world" >> $GITHUB_OUTPUT

We can now use the outputs in the caller workflow, in the same way you would use the outputs from a job within the same workflow. We reference the outputs using the names defined at the workflow level in the reusable workflow: firstword and secondword. In this workflow, job1 calls the reusable workflow and job2 prints the outputs from the reusable workflow ("hello world") to standard output in the workflow log.

YAML

name: Call a reusable workflow and use its outputs

on:
  workflow_dispatch:

jobs:
  job1:
    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1

  job2:
    runs-on: ubuntu-latest
    needs: job1
    steps:
      - run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}

Answered: Explain about the Access and permissions of workflow in gitHub?

Thu, 03 Aug 2023 02:07:35 +0000

A workflow that contains nested reusable workflows will fail if any of the nested workflows is inaccessible to the initial caller workflow.

GITHUB_TOKEN permissions can only be the same or more restrictive in nested workflows. For example, in the workflow chain A > B > C, if workflow A has package: read token permission, then B and C cannot have package: write permission.

For information on how to use the API to determine which workflow files were involved in a particular workflow run

Answered: How can we pass the Passing secrets to nested workflows in Github actions?

Thu, 03 Aug 2023 02:06:11 +0000

You can use jobs.<job_id>.secrets in a calling workflow to pass named secrets to a directly called workflow. Alternatively, you can use jobs.<job_id>.secrets.inherit to pass all of the calling workflow's secrets to a directly called workflow. Secrets are only passed to directly called workflow, so in the workflow chain A > B > C, workflow C will only receive secrets from A if they have been passed from A to B, and then from B to C.

In the following example, workflow A passes all of its secrets to workflow B, by using the inherit keyword, but workflow B only passes one secret to workflow C. Any of the other secrets passed to workflow B are not available to workflow C.

jobs:
  workflowA-calls-workflowB:
    uses: octo-org/example-repo/.github/workflows/B.yml@main
    secrets: inherit # pass all secrets

jobs:
  workflowB-calls-workflowC:
    uses: different-org/example-repo/.github/workflows/C.yml@main
    secrets:
      envPAT: ${{ secrets.envPAT }} # pass just this secret

Answered: Explain about the Nesting reusable workflows in github?

Thu, 03 Aug 2023 02:04:41 +0000

You can connect a maximum of four levels of workflows - that is, the top-level caller workflow and up to three levels of reusable workflows. For example: caller-workflow.yml → called-workflow-1.yml → called-workflow-2.yml → called-workflow-3.yml. Loops in the workflow tree are not permitted.

From within a reusable workflow you can call another reusable workflow.

YAML

name: Reusable workflow

on:
  workflow_call:

jobs:
  call-another-reusable:
    uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1

Answered: What are Supported keywords for jobs that call a reusable workflow in Github Actions?

Tue, 01 Aug 2023 14:09:10 +0000

When you call a reusable workflow, you can only use the following keywords in the job containing the call:

Answered: Explain about matrix strategy with a reusable workflow in Github Actions?

Tue, 01 Aug 2023 14:08:11 +0000

Jobs using the matrix strategy can call a reusable workflow.

A matrix strategy lets you use variables in a single job definition to automatically create multiple job runs that are based on the combinations of the variables. For example, you can use a matrix strategy to pass different inputs to a reusable workflow.

This example job below calls a reusable workflow and references the matrix context by defining the variable target with the values [dev, stage, prod]. It will run three jobs, one for each value in the variable.

YAML

jobs:
  ReuseableMatrixJobForDeployment:
    strategy:
      matrix:
        target: [dev, stage, prod]
    uses: octocat/octo-repo/.github/workflows/deployment.yml@main
    with:
      target: ${{ matrix.target }}

Answered: How can we pass inputs and secrets to a reusable workflow in Github?

Tue, 01 Aug 2023 14:05:39 +0000

Passing inputs and secrets to a reusable workflow

To pass named inputs to a called workflow, use the with keyword in a job. Use the secrets keyword to pass named secrets. For inputs, the data type of the input value must match the type specified in the called workflow (either boolean, number, or string).

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets:
      envPAT: ${{ secrets.envPAT }}

Workflows that call reusable workflows in the same organization or enterprise can use the inherit keyword to implicitly pass the secrets.

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets: inherit

Answered: How to Calling a reusable workflow in github?

Tue, 01 Aug 2023 14:04:07 +0000

You call a reusable workflow by using the uses keyword. Unlike when you are using actions within a workflow, you call reusable workflows directly within a job, and not from within job steps.

jobs.<job_id>.uses

You reference reusable workflow files using one of the following syntaxes:

{owner}/{repo}/.github/workflows/{filename}@{ref} for reusable workflows in public and private repositories.
./.github/workflows/{filename} for reusable workflows in the same repository.

In the first option, {ref} can be a SHA, a release tag, or a branch name. If a release tag and a branch have the same name, the release tag takes precedence over the branch name. Using the commit SHA is the safest option for stability and security.

If you use the second syntax option (without {owner}/{repo} and @{ref}) the called workflow is from the same commit as the caller workflow. Ref prefixes such as refs/heads and refs/tags are not allowed.

You can call multiple workflows, referencing each in a separate job.

jobs:
  call-workflow-1-in-local-repo:
    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89
  call-workflow-2-in-local-repo:
    uses: ./.github/workflows/workflow-2.yml
  call-workflow-in-another-repo:
    uses: octo-org/another-repo/.github/workflows/workflow.yml@v1

Answered: Example of github reusable workflow?

Tue, 01 Aug 2023 14:02:49 +0000

This reusable workflow file named workflow-B.yml, takes an input string and a secret from the caller workflow and uses them in an action.

YAML

name: Reusable workflow example

on:
  workflow_call:
    inputs:
      config-path:
        required: true
        type: string
    secrets:
      token:
        required: true

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/labeler@v4
      with:
        repo-token: ${{ secrets.token }}
        configuration-path: ${{ inputs.config-path }}

Answered: How to Create a reusable workflow of github Actions?

Tue, 01 Aug 2023 14:01:38 +0000

Reusable workflows are YAML-formatted files, very similar to any other workflow file. As with other workflow files, you locate reusable workflows in the .github/workflows directory of a repository. Subdirectories of the workflows directory are not supported.

For a workflow to be reusable, the values for on must include workflow_call:

on:
  workflow_call:

Using inputs and secrets in a reusable workflow

You can define inputs and secrets, which can be passed from the caller workflow and then used within the called workflow. There are three stages to using an input or a secret in a reusable workflow.

In the reusable workflow, use the inputs and secrets keywords to define inputs or secrets that will be passed from a caller workflow.

on:
  workflow_call:
    inputs:
      config-path:
        required: true
        type: string
    secrets:
      envPAT:
        required: true

For details of the syntax for defining inputs and secrets, see on.workflow_call.inputs and on.workflow_call.secrets.

In the reusable workflow, reference the input or secret that you defined in the on key in the previous step.
Note: If the secrets are inherited by using secrets: inherit in the calling workflow, you can reference them even if they are not explicitly defined in the on key. For more information, see "Workflow syntax for GitHub Actions."

jobs:
  reusable_workflow_job:
    runs-on: ubuntu-latest
    environment: production
    steps:
    - uses: actions/labeler@v4
      with:
        repo-token: ${{ secrets.envPAT }}
        configuration-path: ${{ inputs.config-path }}

In the example above, envPAT is an environment secret that's been added to the production environment. This environment is therefore referenced within the job.

Note: Environment secrets are encrypted strings that are stored in an environment that you've defined for a repository. Environment secrets are only available to workflow jobs that reference the appropriate environment. For more information, see "Using environments for deployment."

Pass the input or secret from the caller workflow.

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets:
      envPAT: ${{ secrets.envPAT }}

Workflows that call reusable workflows in the same organization or enterprise can use the inherit keyword to implicitly pass the secrets.

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets: inherit

Answered: what are self-hosted runners in github Actions?

Tue, 01 Aug 2023 14:00:07 +0000

Called workflows that are owned by the same user or organization as the caller workflow can access self-hosted runners from the caller's context. This means that a called workflow can access self-hosted runners that are:

In the caller repository
In the caller repository's organization, provided that the runner has been made available to the caller repository

Answered: What are GitHub-hosted runners?

Tue, 01 Aug 2023 13:58:56 +0000

The assignment of GitHub-hosted runners is always evaluated using only the caller's context. Billing for GitHub-hosted runners is always associated with the caller. The caller workflow cannot use GitHub-hosted runners from the called repository.

Answered: How can we access to reusable workflows in github?

Tue, 01 Aug 2023 13:56:59 +0000

A reusable workflow can be used by another workflow if any of the following is true:

Both workflows are in the same repository.
The called workflow is stored in a public repository, and your organization allows you to use public reusable workflows.
The called workflow is stored in a private repository and the settings for that repository allow it to be accessed.

Answered: what are the difference between Reusable workflows and starter workflows in github?

Tue, 01 Aug 2023 13:56:04 +0000

Starter workflows allow everyone in your organization who has permission to create workflows to do so more quickly and easily. When people create a new workflow, they can choose a starter workflow and some or all of the work of writing the workflow will be done for them. Within a starter workflow, you can also reference reusable workflows to make it easy for people to benefit from reusing centrally managed workflow code. If you use a commit SHA when referencing the reusable workflow, you can ensure that everyone who reuses that workflow will always be using the same YAML code. However, if you reference a reusable workflow by a tag or branch, be sure that you can trust that version of the workflow.

Answered: How to avoid duplication when creating a workflow by reusing existing workflows in Github?

Tue, 01 Aug 2023 13:54:49 +0000

Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow.

Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with actions. Workflow reuse also promotes best practice by helping you to use workflows that are well designed, have already been tested, and have been proven to be effective. Your organization can build up a library of reusable workflows that can be centrally maintained.

The diagram below shows an in-progress workflow run that uses a reusable workflow.

After each of three build jobs on the left of the diagram completes successfully, a dependent job called "Deploy" is run.
The "Deploy" job calls a reusable workflow that contains three jobs: "Staging", "Review", and "Production."
The "Production" deployment job only runs after the "Staging" job has completed successfully.
When a job targets an environment, the workflow run displays a progress bar that shows the number of steps in the job. In the diagram below, the "Production" job contains 8 steps, with step 6 currently being processed.
Using a reusable workflow to run deployment jobs allows you to run those jobs for each build without duplicating code in workflows.

A workflow that uses another workflow is referred to as a "caller" workflow. The reusable workflow is a "called" workflow. One caller workflow can use multiple called workflows. Each called workflow is referenced in a single line. The result is that the caller workflow file may contain just a few lines of YAML, but may perform a large number of tasks when it's run. When you reuse a workflow, the entire called workflow is used, just as if it was part of the caller workflow.

If you reuse a workflow from a different repository, any actions in the called workflow run as if they were part of the caller workflow. For example, if the called workflow uses actions/checkout, the action checks out the contents of the repository that hosts the caller workflow, not the called workflow.

When a reusable workflow is triggered by a caller workflow, the github context is always associated with the caller workflow. The called workflow is automatically granted access to github.token and secrets.GITHUB_TOKEN.

You can view the reused workflows referenced in your GitHub Actions workflows as dependencies in the dependency graph of the repository containing your workflows.

Answered: Is it possible to share actions across different repositories within an organization? If yes, then how?

Tue, 01 Aug 2023 13:52:57 +0000

You can share actions and reusable workflows within your organization, without publishing them publicly, by allowing GitHub Actions workflows to access a private repository that contains the action or reusable workflow.

Any actions or reusable workflows stored in the private repository can be used in workflows defined in other private repositories owned by the same organization. Actions and reusable workflows stored in internal repositories cannot be used in public repositories and actions and reusable workflows stored in private repositories cannot be used in public or internal repositories.

Store the action or reusable workflow in a private repository. For more information, see "About repositories."
Configure the repository to allow access to workflows in other private repositories. For more information, see "Managing GitHub Actions settings for a repository."

Answered: In which languages write actions for GitHub?

Tue, 01 Aug 2023 13:51:18 +0000

We can write actions for GitHub in any language that can run on Linux, including but not limited to Bash, JavaScript, and Python.

Answered: What’s a good way to get started with writing my first action in GitHub?

Tue, 01 Aug 2023 13:40:44 +0000

A good way to get started with writing your first action in GitHub is to start by looking at the existing actions that are available and see if any of them can be adapted to your needs. Once you have a good understanding of how actions work, you can start writing your own custom action by following the instructions in the GitHub Actions documentation.

Answered: Can you give me some examples of common workflows that can be automated by using GitHub Actions?

Tue, 01 Aug 2023 13:40:01 +0000

There are a lot of different workflows that can be automated by using GitHub Actions. For example, you could set up a workflow to automatically build and deploy your code whenever you push a new commit to your GitHub repository. Or, you could set up a workflow to run a series of tests on your code every time you open a new pull request. There are endless possibilities for what you can do with GitHub Actions, so it really depends on what you need to automate in your particular workflow.