error parsing called workflow in github . workflow was not found - github

Trying to use pulumi preview with Github actions. The workflow file is giving me the below error.
Invalid workflow file: .github/workflows/pull_request.yml#L12
error parsing called workflow "peopleticker/ccc/.github/workflows/pull_request.yml#master": workflow was not found.
I'm using the workflow file below kindly check:
name: Call a reusable workflow
permissions:
id-token: write
contents: read
on:
pull_request:
jobs:
call-workflow-passing-data:
uses: peopleticker/ccc/.github/workflows/pull_request.yml#master

According to GitHub document:
doc
You can visit repository Setting -> Actions -> Access: Choose "Accessible from repositories in the organization"

You can't use reusable workflows from other private repositories.
Reusable workflows stored within a private repository can only be used by workflows within the same repository.
source

You can use private repo workflows but you have to give access on org level.
Github give access that.
Related documentaion: github-doc
Example Video Explanation: video-expl

Related

Azure Devops - Muliple Repos Triggers

Has the Following Feature has been implemented for Gihub Repos yet?strong text
Multi-repo triggers
You can specify multiple repositories in one YAML file and cause a pipeline to trigger by updates to any of the repositories. This feature is useful, for instance, in the following scenarios:
You consume a tool or a library from a different repository. You want to run tests for your application whenever the tool or library is updated.
You keep your YAML file in a separate repository from the application code. You want to trigger the pipeline every time an update is pushed to the application repository.
With this update, multi-repo triggers will only work for Git repositories in Azure Repos. They don't work for GitHub or Bitbucket repository resources.
SAMPLE :
trigger:
main
resources:
repositories:
- repository: tools
type: git
name: MyProject/tools
ref: main
trigger:
branches:
include:
- main
- release
As per Microsoft official sprint 173 updates 2020, this is achiveable using resources tag inside your yaml.
Here is an example that shows how you can setup an auto trigger inside your yaml pipeline based on any change in any other repos inside the same project and even other projects inside Azure DevOps as well.
Sample:
trigger:
- main
resources:
repositories:
- repository: tools
type: git
name: MyProject/tools
ref: main
trigger:
branches:
include:
- main
- release
In the above code snippet:
main branch in the self repo containing the YAML file
main or release branches in tools repo
Here is the link for official documentation form Microsoft for further details.
Hope that solution works for you.
Repository resource triggers only work for Azure Repos Git repositories in the same organization at present. They do not work for GitHub or Bitbucket repository resources.
Refer to this official doc for details: https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops#triggers
If you would like this feature to be supported, create a feature request: https://developercommunity.visualstudio.com/AzureDevOps/suggest

Sharing GitHub actions with Enterprise

Overview
The GitHub documentation suggests that actions can be shared between repositories within an enterprise. However, when I try to use an action from inside my enterprise from another repository I get the error:
Error: Unable to clone https://github.com/Org1/action refs/heads/workflow-test: repository not found
Current set up
We have two organizations Org1 and Org2 that are both in the same enterprise. Org1 contains an repository containing an action: Org1/action. Org2 contains a repository which would like to consume this action: Org2/consumer.
I have followed this documentation: https://docs.github.com/en/enterprise-cloud#latest/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise.
Org1/action
Visibility is set to internal although it was originally private.
I have set Settings>Actions>General>Access to Accessible from repositories in the 'ENTERPRISE NAME' enterprise
Org2/consumer
This repository is set to allow all actions and reusable workflows.
Problem
There is no good documentation on GitHub which explains how to consume actions from within the enterprise.
This is what we currently have in Org2/consumer:
Name: Load test
on: [push]
jobs:
run_action:
runs-on: self-hosted
name: Action
steps:
- name: Trigger Load Test
uses: Org1/action#workflow-test # the action is on this branch
id: action
When we run this action we get the error displayed in the Overview section. This seems like an issue with how the runner is authorizing with GitHub when pulling the repository.
I would love to know if anyone has overcome this issue, or if they have found a work around.
Thanks in advance.

Trying to refer a Reusbale Workflow from a Private repo

I am trying to find a workaround for using a Reusable workflow between two private repos: (It is not supported natively)
Context: I am trying to use a central repo (private) to contain all the Workflows and refer to that location from other repos (private).
Legend:
Central Repo: Contains all the Reusable Workflows. (If we edit a file in here we should not have to edit each and every repo's workflow files)
Calling Repo: A repo which runs Workflows, This repo will try to refer the workflows from the Central repo.
name: Calling Reusable Workflows
on: [ push ]
jobs:
download-remote-repo:
runs-on: ubuntu-latest
steps:
- name: Get private repo with action
uses: actions/checkout#v2
with:
repository: kalanatd/central-repo
ref: main
token: ${{ secrets.PAT_TOKEN }}
- name: List Files After remote Checkout
run: |
pwd
ls -a // I can see the checked out remote repo files in here
ls -al .github/workflows
cat ./.github/workflows/workflow.yml // Can read the file without any issue
- name: Run a workflow file
uses: ./.github/workflows/workflow.yml
Note: In aboe scenario ./.github/workflows/workflow.yml is dynamically checked out to the Runner's workspace. Even though 'run' commands can see that file 'uses' command does not use it.
[1] Error: Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/caller-repo/caller-repo/workflow.yml'. Did you forget to run actions/checkout before running your local action?
[2] https://github.github.io/actions-cheat-sheet/actions-cheat-sheet.pdf
Note:
I learned that RWs can not be called under steps which means there is no way to download a RW from another place and use that workflow, right?
I am trying to find a workaround for using a Reusable workflow between two private repos: (It is not supported natively)
Actually... it is, at least on GitHub (and later on a private GHE instance)
GitHub Actions – Sharing actions and reusable workflows from private repositories is now GA (Dec. 2022)
The actions and reusable workflows from private repositories can now be shared with other private repositories within the same organization, user account, or enterprise.
See managing the repository settings and managing the enterprise repository settings to allow access to workflows in other repositories.
We have also added the API support to configure Actions share policy.
Refer to API support or API support for Enterprise for more details.
Learn more about Sharing actions and workflows from your private repository, Sharing actions and workflows with your organization, and Sharing Actions and workflows with your enterprise.

Github actions suddenly throwing "no version specified" for reusable workflows that worked yesterday

I'm not sure if this is a bug or a breaking change happened as of yesterday, I have a pretty simple setup calling three reusable workflows:
name: pr-checks
on:
pull_request:
branches: "**"
jobs:
lint:
name: Call Lint
uses: ./.github/checks/check-lint.yaml
test:
name: Call Test
uses: ./.github/checks/check-test.yaml
e2e:
name: Call E2E
uses: ./.github/checks/check-e2e.yaml
But this throws
"invalid value workflow reference: no version specified"
as of now, even though identical workflows have worked yesterday.
When reusing workflows like this at the 'job' level - it is not necessary to specify version, in fact, it used to error out if I specified the version.
Screenshots attached as I think this doesn't make much sense.
I did click on 're-run all jobs and it re-ran successfully.
However, without any discenrable difference and after also removing the build step just to be sure there's nothing weird happening there:
As you can see in your 2 screenshots, one is referring to the .github/workflows directory (the one which worked), and the other to the .github/checks directory (the one which didn't).
Short answer: If you change the workflow folder back to workflows instead of checks, it should work as expected.
Long answer: It seems there is a confusion between the syntax of two different concepts:
local actions (using an action in the same repo)
reusable workflows (reusing the same workflow in different workflows)
LOCAL ACTIONS
To access local actions (folders with action.yml file) from your workflow, you need to use the actions/checkout first, to allow it to access the other repository folders and files.
Example:
steps:
- uses: actions/checkout#v3 # Necessary to access local action
- name: Local Action Call
uses: ./.github/actions/local-action #path/to/action
I've made a POC here some time ago if you want to have a look.
REUSABLE WORKFLOWS
Now, if you want to use reusable workflows, the issue is different:
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.
GitHub documentation reference
In that case, according to this other section from the documentation:
You reference reusable workflow files using one of the following
syntaxes:
{owner}/{repo}/.github/workflows/{filename}#{ref} for reusable
workflows in public repositories.
./.github/workflows/{filename} for reusable workflows in the same repository.
{ref} can be a SHA, a release tag, or a branch name.
Example:
lint:
name: Call Lint
uses: ./.github/workflows/check-lint.yaml#{SHA/TAG/BRANCH}
or
lint:
name: Call Lint
uses: ./.github/workflows/check-lint.yaml
Here is another POC for the workflow call using this reusable workflow
CONCLUSION
It's like you were trying to call a reusable workflow as if it was a local action, which won't work as reusable workflows need to be located in the .github/workflows directory.
Note that you could eventually add the #branch-name at the end of the workflow call to be sure to use the workflow from the branch you want to test if the reusable workflow is already present on the default branch.

azure devops triggers trouble understanding

I've got a problem where I cannot get my pipeline to run when I want it to.
Background
I have a repo in GitHub, and I'm running my pipelines in ADO.
I have two branch - main branch, feature branch.
I want a pull request to trigger a pipeline called "pull-request" when I make a pull request in github.com. I want the pipeline to exclude any changes that happen to a file called azure-pipeline-pull-request.yml (which is the pipeline file).
I don't want it to run any other time.
I have tried many different combos in the yml file, but I cannot get the pipeline to run when a PR happens.
This is the code at the top of the YAML file.
trigger:
branches:
include:
- main
paths:
exclude:
- azure-pipelines-pull-request.yml
pr:
branches:
include:
- main
paths:
exclude:
- azure-pipelines-pull-request.yml
I've tried it without the trigger section. I could do with some help in explaining what is happening.
I tried your code and successfully triggered the pipeline to run. So some other reasons caused the pipeline not running automatically instead of your script.
There are several possible reasons for the issue. Click I just created a new YAML pipeline with CI/PR triggers, but the pipeline is not being triggered. for detailed information and steps. Here is a brief overview of the content of the document:
Go to "Triggers" in UI. Turn off the "Override the YAML trigger from here" setting.
Check whether your Github repository is connected to multiple Azure DevOps organizations. If so, remove the service connection and re-establish it.
Check whether there is a failure in Webhooks in Github.
Make sure that the YAML file in the correct branch has the necessary CI or PR configuration.
Did you use templates for your YAML file? If so, make sure that your triggers are defined in the main YAML file.