I have around 10 individual micro-services which are mostly cloud functions for various data processing jobs, which all live in a single github repository.
The goal is to trigger the selective deployment of these service to Google Cloud Functions, on push to a branch - when an individual function has been updated.
I must avoid the situation in which update of a single service causes the deployment of all the cloud functions.
My current repository structure:
/repo
--/service_A
----/function
----/notebook
--/service_B
----/function
----/notebook
On a side note, what are the pros/cons of using Github Actions VS Google Cloud Build for such automation?
GitHub Actions supports monorepos with path filtering for workflows. You can create a workflow to selectively trigger when files on a specific path change.
https://help.github.com/en/articles/workflow-syntax-for-github-actions#onpushpull_requestpaths
For example, this workflow will trigger on a push when any files under the path service_A/ have changed (note the ** glob to match files in nested directories).
on:
push:
paths:
- 'service_A/**'
You could also run some script to discover which services were changed based on git diff and trigger corresponding job via GitHub REST API.
There could be two workflows main.yml and services.yml.
Main workflow will be configured to be started always on push and it will only start script to find out which services were changed. For each changed service repository dispatch event will be triggered with service name in payload.
Services workflow will be configured to be started on repository_dispatch and it will contain one job for each service. Jobs would have additional condition based on event payload.
See showcase with similar setup:
https://github.com/zladovan/monorepo
It's not a Monorepo
If you only have apps, then I'm sorry... but all you have is a repo of many apps.
A monorepo is a collection of packages that you can map a graph of dependencies between.
Aha, I have a monorepo
But if you have a collection of packges which depend on each other, then read on.
apps/
one/
depends:
pkg/foo
two/
depends:
pkg/bar
pkg/foo
pkg/
foo/
bar/
baz/
The answer is that you switch to a tool that can describe which packages have changed between the current git ref and some other git ref.
The following two examples runs the release npm script on each package that changed under apps/* and all the packges they would depend on.
I'm unsure if the pnpm method silently skips packages that don't have a release target/command/script.
Use NX Dev
Using NX.dev, it will work it out for you with its nx affected command.
you need a nx.json in the root of your monorepo
it assumes you're using the package.json approach with nx.dev, if you have project.json in each package, then the target would reside there.
your CI would then look like:
pnpx nx affected --target=release
Pnpm Filtering
Your other option is to switch to pnpm and use its filtering syntax:
pnpm --filter "...{apps/**}[origin/master]" release
Naive Path Filtering
If you just try and rely on "which paths" changed in this git commit, then you miss out on transient changes that affect the packages you actually want to deploy.
If you have a github action like:
on:
push:
paths:
- 'app/**'
Then you won't ever get any builds for when you only push commits that change anything in pkg/**.
Other interesting github actions
https://github.com/marketplace/actions/nx-check-changes
https://github.com/marketplace/actions/nx-affected-dependencies-action
https://github.com/marketplace/actions/nx-affected-list (a non nx alternative here is dorny/paths-filter
https://github.com/marketplace/actions/nx-affected-matrix
Has Changed Path Action might be worth a try:
name: Conditional Deploy
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
fetch-depth: 100
- uses: marceloprado/has-changed-path#v1
id: service_A_deployment
with:
paths: service_A
- name: Deploy front
if: steps.service_A_deployment.outputs.changed == 'true'
run: /deploy-service_A.sh
Related
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.
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.
I would like to run a yaml pipeline from one project. I have a task in my yaml to scan all the source code. Using this Yaml I would like to scan all the source code in master branch for all the project and all the repository inside the same Org.
How can I get all the repo for all the project and iterate? Can someone help me ?
test.yaml
repositories:
- repository: justAnotherName
type: github
name: myGitRepo
endpoint: myGitServiceConnection
trigger:
branches:
include:
- master
steps:
- task: CredScan#2
inputs:
toolMajorVersion: 'V2'
outputFormat: 'tsv'
scanFolder: '$(Build.SourcesDirectory)'
If you're looking to pull every repo within a project, you have one of two options (see below). However, I'd advise caution before attempting this on a Microsoft-hosted agent, they have a 60-minute timeout by default. If you're using a self-hosted agent, you need not worry. I'd still advise breaking this up to avoid creating a long-running release that also consumes a large amount of disk space with each run.
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#timeouts
That being said, here are the options you have:
Option 1 (Not the best)
Manually add a repository: dependency for every project and a checkout: task for every repo within the projects.
This is heavily manual and would require maintenance every time a report is added.
Option 2
You can write a custom PowerShell/bash script that uses the Azure DevOps API and git to automatically scan all projects and repos within the org and pull them onto the machine.
Start by issuing a request to get all of the projects within the org:
https://learn.microsoft.com/en-us/rest/api/azure/devops/core/projects/list?view=azure-devops-rest-6.0
Then, iterate through every project and get all repos:
https://learn.microsoft.com/en-us/rest/api/azure/devops/git/repositories/list?view=azure-devops-rest-6.0
Finally, iterate through each repo and run git clone [repository URL] to clone it onto the build agent.
NOTE: You will want to ensure to have a lot of free disk space on the agent machine and that you clean up the build space after this operation.
I'm trying to use GitHub to trigger on PR a GitLab pipeline.
Practically when a developer creates a PR in GitHub, his/her code get tested against a GitLab pipeline.
I'm trying to follow this user guide: https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html
and we have a silver account, but it won't work. When creating the PR, the GitLab pipeline is not triggered.
Anyone with this kind of experience who can help?
Thanks
Joe
I've found the cause of the issue.
In order for GitHub to trigger GitLab as CD/CI mostly in PR request, you need to have a Silver/Premium account AND, very important, being the root owner.
Any other case, you won't be able to see github in the integration list on GitLab. People from gitlab had the brilliant idea to hide it instead of showing it disabled (which would had been a tip to understand that you needed an upgraded license)
In the video above it's not explained.
Firstly, you need to give us the content of your .gitlab-ci.yaml file. In your question you asked about GitHub but you're following Gitlab documentation which is completely different. Both are using git commands to commit and push repos but Github & Gitlab are different.
For Github pipelines, you need to create a repository, then you go to Actions. Github will propose you to configure a .github/workflows directory which contain a file.yaml. In this .yaml file you can code your pipelines. According to your project, Github will propose you several linux machines with the adequate configuration to run your files (If it's a Java Project --> you'll be proposed maven machines, Python --> Python Machines, React/Angular -> machines with npm installed, Docker, Kubernetes for deployments...) and you're limited to 4 private project as far as I know (check this last information).
For Gitlab you have two options, you can use preconfigured machines like github, and you call them by adding for example atag: npm in your .gitlab-ci.yaml file, to call a machine with npm installed, but you need to pay an amount of money. Or you can configure your own runners by following the Gitlab documentation with gitlab commands (which is the best option), but you'll need good machines and servers to run npm - mvn - python3 - ... commands
Of course, in your Gitlab repository, and finally to answer your question this an example, of .gitlab-ci.yaml file with two simple stages: build & test, the only statement specifies that these pipelines will run if there is a merge request ( I use the preconfigured machines of Gitlab as a sample here) More details on my python github project https://github.com/mehdimaaref7/Scrapping-Sentiment-Analysis and for gitlab https://docs.gitlab.com/runner/
stages:
- build
- test
build:
tags:
- shell
- linux
stage: build
script:
- echo "Building"
- mkdir build
- touch build/info.txt
artifacts:
paths:
- build/
only:
- merge_requests
test:
tags:
- shell
- linux
stage: test
script:
- echo "Testing"
- test -f "build/info.txt"
only:
- merge_requests
I've added GitHub Actions Workflow to my repo and tried to configure it but failed. Checked few websites but couldn't find a clear answer. How can one configure its Workflow so that C++ CI/Build would build each directory separately whenever I push something to the repository?
Note: My repo contains several folders of source code and each has different project/code snippets.
You can filter each workflow to only run when commits affect files in a certain path:
https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'