I have added github workflow and its corresponding yaml files in branch A, this branch also contains the package.json and other files to run cypress tests. I am planning on triggering these tests whenever the push happens to branch B, I tried adding the on Push Branch B, but for some reason this trigger only works whenever I move the workflow file to branch B.
Why is this happening and is there a way I can have the existing folder structure and trigger the scripts via workflow file
This is expected behavior. If you want workflow to be run on push in a particular branch, the workflow has to be in that branch.
You usually add workflow to your master branch so that it is present in every newly created branch and specify when to run it in on key - this is the recommended way and probably what you want.
There is however a possible solution to run action from a different branch. You can convert workflow to an action.
Then you need to create a workflow in branch B that will checkout branch A and trigger the action. Also, checkout to specified folder so that there are no conflicts.
Simple example:
workflow-in-b-branch.yml
jobs:
reusable_action_job:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
ref: branch-A
path: branch-a
- uses: ./branch-a/.github/actions/action-name
Related
I've recently applied the multistage YAML for my project, which consists of both CI and CD.
Afterwards I setup the branch policies to only trigger the CI portion when a pull request was created, by adding condition into the CD stage to skip it.
trigger:
branches:
include:
- master
paths:
include:
...
stages:
- stage: Build
jobs:
- job: Build
pool:
vmImage: 'windows-latest'
steps:
...
- stage: Deploy
condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
displayName: 'Deploy'
jobs:
...
Once the pull request completed, the whole CI/CD part triggered again as master branch has new code pushed in. Is there a way to prevent the CI from running again, or download the artifact from previous run, so to kind of "resume" the CD?
The idea is to run only the CI when pull request created, and to continue for CD when pull request completed.
Resolved by splitting CI and CD into 2 yaml files, with CD consuming artifacts from CI.
When PR set the triggers in branch policies with path filter for specify CI, and CD set as trigger by same branch with same path filter. This way CD will triggers after PR completed since the branch got updated, and then it will downloads artifacts created by CI during PR.
good day. i try to ask same question on teamcity support forum but with no luck, so i try to find solution here
i have 4 (actual more, but other configuration not important for the situation):
'verify' - configuration that run test, check that all migration can be applied to database (run in docker) etc. this configuration triggered by gitlab (integration with teamcity feature)
'build' - configuration that build all application components and push docker images to hub
'deploy to test' - use corresponded artifacts from 'build' configuration and perform deploy images to test server
'deploy to staging' - same as 'deploy to test' but use staging server
'deploy to production' - same as 'deploy to production' but use production server
we have several stream in out repository with corresponded rules:
develop
feature/* - feature task that should be build then corresponded merge request to develop was initiated. merged to develop
release/* - release that should be deployed to staging server at each commit. merged to develop and master
hotfix/* - hotfix that should be deployed to staging server at each commit. merged into develop and master
master - stable branch, should be deployed to production on commit.
so, i create following VCS root:
default branch: refs/heads/develop
branch specification:
+:refs/heads/(*)
+:refs/heads/master
+:refs/heads/release/*
+:refs/heads/feature/*
+:refs/heads/hotfix/*
+:refs/(merge-requests/*)
after that i setup branch filters (for VCS Trigger) for each branch configuration:
verify - none
build:
+:refs/heads/release/*
+:refs/heads/hotfix/*
+:refs/heads/develop
+:refs/heads/master
deploy to staging:
+:refs/heads/master
+:refs/heads/release/*
+:refs/heads/hotfix/*
deploy to test:
+:refs/heads/develop
deploy to production:
+:refs/heads/master
so this is my setup, now my problems:
then gitlab trigger teamcity (on merge request) the verify configuration started. but i see following message (for example):
The build was triggered in the branch feature/VTS-610 which does not correspond to any branch monitored by the build VCS roots (the branch is either closed or excluded / not matched by any branch specification). Because of that default branch revisions were set to this build.
same message i can see if merge request initiated for hotfix branch (of course with another branch name, ie hotfix/VTS-654).
after hotfix branch merged (we create two merge-request: one to master and one to develop), i can see that deploy to staging was triggered, but deploy to test does not.
I had the same problem, the root cause in my case was the predefined build parameter teamcity.build.branch (see Build Branch Parameters)
The parameter was set in the build configuration of the failing build under "Parameters / Configuration Parameters". As I had no use for this parameter anymore, it was safe to just delete it. I was then able to run the build configuration with any branch that is accepted in the Branch Filter under Version Control Settings.
This is a bit unconventional but I am trying to set an automated testing suite that involves 3 repos; the iOS/android app repos and another for our python tests which use appium. Everything works manually but now we would like to set it up with github actions or circleci.
This is the ideal workflow I have in my mind; our frontend developer creates a new release on GH, that sends a trigger which creates a new app build and then triggers the test repo which will run the tests on that new build.
I've been able to set up workflows where one repos actions triggers something on a different repo with GHA repo dispatch, but what i'm unable to figure out is getting the new build from one repo to another. Is it even possible? If it's not, is there a way to get that new app build into my test repo another way?
Im a junior dev and this is my first attempt at setting up continuous integration so any help is appreciated!
To let your test repository know what it should be testing you can send it the git commit SHA of the release when you trigger a repository_dispatch.
- name: Repository Dispatch
uses: peter-evans/repository-dispatch#v1
with:
token: ${{ secrets.PAT }}
repository: org/test-repo
event-type: my-event
client-payload: '{"sha": "${{ github.sha }}"}'
Then you can checkout that SHA in the test repository workflow and test it.
name: Repository Dispatch
on:
repository_dispatch:
types: [my-event]
jobs:
myEvent:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
token: ${{ secrets.PAT }}
repository: org/build-repo
ref: ${{ github.event.client_payload.sha }}
Note that in both workflows you need to use a repo scoped PAT.
In general, it is best to test build artifacts before they are released. So you might want to think about redesigning slightly to run your tests earlier in the pipeline. Perhaps on push to master, or testing pull request branches before they merge to master, etc.
We have currently three separated appveyor projects, one for each branch in our repository.
Our problem is follwing:
Appveyor ignores my filter on github branches. Everytime we make a commit to master, stage or dev it builds on all three projects instead of the single one we did make a commit to.
Each branch has a unique appveyor.yml file looking like this:
This is the appveyor.yml for dev
version: 0.0.{build}
branches:
only:
- dev
image: Visual Studio 2017
configuration: dev
before_build:
- nuget restore
build:
project: Core.Api.sln
publish_wap: true
verbosity: minimal
build_script:
- ps: .\build.ps1
after_build:
- cmd: dotnet publish src\Core.Api --output %appveyor_build_folder%\dist
test: off
artifacts:
- path: dist
name: dist.web
deploy:
...
When we make a commit, it builds on all projects. Any idea??
This happens because each project has Webhook configured on GitHub and each time someone makes a commit, each project build is triggered by webhook. Then, regardless of what branch is configured for project (that is only default branch for manual/API builds), AppVeyor reads appveyor.yml from the branch where commit was done.
Solution is to use either alternative YAML file names or alternative YAML file location.
With alternative YAML file names you can have something like appveyor-dev.yml, appveyor-stage.yml files and set specific AppVeyor project to use specific file. With alternative YAML file location is it basically the same, but in other location than repo. I personally like alternative YAML file location more because of less duplication and potential merging issues.
In both cases when webhook in say branch dev come to stage project, it still will read appveyor-dev.yml and do the right filtering.
I am new to using bitbucket was trying just to set up simple build pipeline. Clicked on pipeline menu option and edited the example file and committed. This created a pipeline yaml file on my master branch. It ran and built ok - it did not build my develop branch.
Do i need a pipeline yaml file on each branch.
I can see from docs that i can put branch specific steps into the one file, if i edit the file that has been commited on master to include a section for the develop branch, will this run when i do a commit to the develop branch or will this only trigger on a commit to master branch.
Bitbucket will run the pipelines that has a corresponding definition for the branch that you have commited to. So, if you commit the pipelines configuration file to master, only default or master pipeline from this file will be executed. If you want to run a pipeline for develop branch, you need to commit this file to develop branch as well. Note, that the default pipeline is executed regardless of the branch name if there is no other pipeline defined for this particular branch. So, your comment is correct, you need to have the bitbucket-pipelines.yml in each branch.
Here is how Bitbucket will resolve the pipeline execution configuration^
If there is no bitbucket-pipelines.yml - no pipelines will run for the branch
If there is bitbucket-pipelines.yml and there is a default pipeline definition only, Bitbucket will execute the default pipeline.
pipelines:
default:
- step:
script:
- echo "Running the default pipeline"
If there is also a specific pipeline defined for a particular branch, lets say for develop, Bitbucket will execute this pipeline instead of the default
pipelines:
default:
- step:
script:
- echo "This will not be executed if the branch is develop"
develop:
- step:
script:
- echo "Running the develop pipeline"
Note, that if the branch name would be something else, lets say release, since there is no pipeline defined for release branch, the default pipeline will be executed.