I have two branches i.e. main and develop. I want to run code with GitHub Actions for branch main (Production) and for develop (Staging) on schedule (nightly).
I've read that the workflow schedule can only be configured for the default branch on GitHub. So, what implementation for the workflow.yaml would be?
Yes, according to schedule:
Scheduled workflows run on the latest commit on the default or base branch.
However, it looks like it's doable by configuring the cron job for the default branch and then somehow triggering the workflow for the non-default branch e.g. using the GitHub API or CLI.
See workflow_dispatch for more details.
Or, via workflow_run configuration after completion of the workflow on the default branch. Though, in this case, you might not want to combine both in general scenarios.
Related
I am wondering if there is any way to do the following. Say I have an "open data" repo, which allows people to submit content. The repo saves all the data, and the changes to the structured JSON/YAML is reviewed in a PR. But then because I am in a serverless system (like Vercel), I need to upload the changes to the data to the production database, on merge of the branch. So there should be required a custom data migration in the PR, which runs when the PR is approved and merged.
How can that be accomplished? All I can imagine as a solution is having a special "code block" in markdown with some JSON config explaining what script to run for the data migration, and you add that marked code snippet as a comment to the PR, then parse the PR comments and figure out what script to run from that. But that would be of course (seemingly) a super hack, so is there a right way to do something like this?
The other option is to have to run the script/command manually after you merge the PR, but ideally there would be a more automatic way of doing it.
GitHub itself can run code on various events through actions. Actions are configured through YAML files in the directory .github/workflows in the repository. Some actions relative to a branch use the workflow files from that branch, while “global” actions use the workflow files from the default branch (typically called main, or master for older repositories).
For example, this workflow runs bin/update-production-database whenever the main branch is updated (whether from a pull request merge or by pushing directly):
name: Update database
on:
push:
branches:
- main
jobs:
update-database:
runs-on: ubuntu-latest
steps:
- run: bin/update-production-database
See more examples in Deploying with GitHub Actions. To pass the credentials needed to access the database, set up an encrypted secret.
To only run the job on a PR merge and not on other pushes, see Running your workflow when a pull request merges.
If you use Vercel (which I know nothing about), it claims it “automatically deploys your GitHub projects” so there may be a built-in solution there (either using actions so that the trigger comes from GitHub, or using some Vercel-owned server which polls GitHub).
Description:
I am trying to have Github webhook to trigger my Jenkins job. I am successful in triggering the job using the Main branch but no success using other branches. I have a new branch called 'develop' but it does not trigger the job.
Current Setup:
In Jenkins, I am using Pipeline -> Pipeline Script from SCM.
Under SCM, My repository is defined and it can access Main branch pr
But when I change it to other branch like 'develop', It does not work.
Is there additional configuration to use other branches?
Apparently, the input is accepting Regular Expression. The initial specified branch is '*/master'. Therefore, I used '*/develop' to trigger my Jenkins job for develop branch
I am currently configuring a Jenkins server hosted on a Docker container in AWS.
I am using BlueOcean to configure a repository.
Right now, the pipeline scans all branches on a repository to detect Jenkinsfiles and then will automatically build on that branch if it detects changes. I scan the repo every 5 minutes to detect changes.
However, I do not want to be running builds and jobs automatically if it is some random feature branch. I am trying to limit the automatically triggered builds to only changes in staging and master branches.
So my question is, how/where do you configure Jenkins GitHub pipeline to only build on certain branches rather than scanning all branches?
A Multibranch pipeline job is your friend.
Rather than trying to limit which branches Jenkins is polling firstly what I do in my Jenkinsfile is poll source control every minute:
triggers { pollSCM('* * * * *') }
This will poll every branch and create a job where it finds a Jenkinsfile in the location and name you specify in the Multibranch Pipeline job configuration.
Side Note
About the only configuration in a multibranch pipeline is:
Where's the SCM repo?
Workspace relative path and name of Jenkinsfile. (You can call it Bob if you want)
A multibranch pipeline job sets an additional environment variable: BRANCH_NAME which allows you to conditionally perform actions in pipeline like so:
script {
if( "${env.BRANCH_NAME}" == "integration" ) {
//Do something useful
}
}
Using this method you can also decide to do nothing in response to a poll event.
I assume you are using github plugin. I'd suggest configuring a webhook on your repository using Generic Webhook Trigger Plugin - https://wiki.jenkins.io/display/JENKINS/Generic+Webhook+Trigger+Plugin
This plugin is awesome and lets you easily extract the values in the incoming webhook and use those in your pipeline. For ex. you can extract the branch from where the webhook came from and only build if the branch is staging or master
In our setup we use a simple job 'webhook trigger processor' which reads the incoming webhook from all repositories and triggers downstream pipelines using values extracted from webhook.
Pipeline accepts input parameters. So you can create a parameter called branch.
Inside your pipeline you could use regex to match only required branches.
I am new to working with Jenkins pipeline. I am able to use the GitHub Plugin in Jenkins and Webhooks from GitHub to successfully build a specific branch of a repository for a free style job. I can't find documentation that documents how to setup the "Source Code Management" so that only specific branches are build based on the github webhook.
For now I can chain the pipeline job to a free style job so that I can build only specific branches. I would rather have the pipeline job configured specifically for the branch we are trying to build.
Thanks in advance for your help!
SCM Configuration for the pipeline job.
!https://i.stack.imgur.com/0NoOX.png
In order to accomplish this within a Jenkins Pipeline job, you must mark the Pipeline Definition as "Pipeline script from SCM". This will instruct Jenkins to base the pipeline execution based on a Jenkinsfile within the repository. Here, you can also instruct Jenkins which branches to build.
From there, you simply need to make sure that your GitHub pushes are triggering builds within Jenkins correctly, and that's all there is to it!
The goal of the pipeline job was to build and deploy specific branch automatically. The approach was to create a pipeline job and define the branch in the SCM configuration and enable webhooks so that the branch would automatically build when a new commit is pushed. Unfortunately the webhook SCM build for pipeline is broken or is not supported for webhooks.
We have decided to change our approach and use the multibranch pipeline job. This by default build ALL branches that have a jenkinsFile. We are filtering in the job for the specific branches we want automatically build.
I have a CI build that is setup in TeamCity that will trigger when a pull request is made in BitBucket (git). It currently builds against the source branch of the pull request but it would be more meaningful if it could build the merged pull request.
My research has left me with the following possible solutions:
Script run as part of build - rather not do it this way if possible
Server/agent plugin - not found enough documentation to figure out if this is possible
Has anyone done this before in TeamCity or have suggestions on how I can achieve it?
Update: (based on John Hoerr answer)
Alternate solution - forget about TeamCity doing the merge, use BitBucket web hooks to create a merged branch like github does and follow John Hoerr's answer.
Add a Branch Specification refs/pull-requests/*/merge to the project's VCS Root. This will cause TeamCity to monitor merged output of pull requests for the default branch.
It sounds to me like the functionality you're looking for is provided via the 'Remote Run' feature of TeamCity. This is basically a personal build with the merged sources and the target merge branch.
https://confluence.jetbrains.com/display/TCD8/Branch+Remote+Run+Trigger
"These branches are regular version control branches and TeamCity does not manage them (i.e. if you no longer need the branch you would need to delete the branch using regular version control means).
By default TeamCity triggers a personal build for the user detected in the last commit of the branch. You might also specify TeamCity user in the name of the branch. To do that use a placeholder TEAMCITY_USERNAME in the pattern and your TeamCity username in the name of the branch, for example pattern remote-run/TEAMCITY_USERNAME/* will match a branch remote-run/joe/my_feature and start a personal build for the TeamCity user joe (if such user exists)."
Then setup a custom "Pull Request Created" Webhook in Bitbucket.
https://confluence.atlassian.com/display/BITBUCKET/Tutorial%3A+Create+and+Trigger+a+Webhook
So for your particular use case with BitBucket integration, you could utilize the WebHook you create, and then have a shell / bash script (depending on your TeamCity Server OS) that runs the remote run git commands automatically, which will in turn automatically trigger the TeamCity Remote Run CI build on your server. You'll then be able to go to the TeamCity UI, +HEAD:remote-run/my_feature branch, and view the Remote Run results on a per-feature basis, and be confident in the build results of the code you merge to your main line of code.
Seems that BitBucket/Stash creates branches for pull requests under:
refs/pull-requests//from
You should be able to setup a remote run for that location, either by the Teamcity run-from-branch feature, or by a http post receive hook in BitBucket/Stash.
You can also use this plugin : https://github.com/ArcBees/teamcity-plugins/wiki/Configuring-Bitbucket-Pull-Requests-Plugin
(Full disclosure : I'm the main contributor :P, and I use it every day)