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).
Related
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.
I'm setting up Github actions for a few of my projects.
The flow I'd like to achieve is:
A developer clicks on the "Merge pull request" button
A Github action testing workflow will take place
If the tests pass - The merge is executed
The reason for this kind of flow, is I wouldn't like the tests to run on each commit pushed to the branch. I want the flow to run only when trying to merge.
My question is:
Is there a way to manually execute a workflow only when trying / wanting to merge, and making sure the branch can be merged into master if and only if the tests have passed?
Unfortunately, there's no merged or merge_attempt activity type on the pull request event (yet). Even if there was, I don't believe GitHub has a way to block merges on the completion of a workflow (yet).
What I would suggest as a workaround here is to run your test 1. after the fact on pushes to the master branch, and 2. on pull_request events with certain activity types which indicate that the user is likely to attempt a merge soon. For example, ready_for_review or review_requested.
Something like this:
name: tests
on:
push:
branches:
- master
pull_request:
branches:
- master
types:
- ready_for_review
- review_requested
I am trying to use Azure Pipelines to build a docker container. Everything works great except for the fact that the pipeline runs on every branch push (and builds all the way) when in fact I would like it to build only on tags that start with "v".
I am using bitbucket for git repo.
I've looked online and as far as I can tell from examples, my yml should be working
My trigger looks like this:
trigger:
tags:
include:
- 'v*'
branches:
exclude:
- '*'
Unfortunately with this configuration, my pipeline builds on every branch instead of tags only.
I would like to be able to automatically build on pushing tags only, no branches, no PRs (right now it builds on branches and PRs but not on tags, at all).
Thanks!
EDIT: looks like merge (pull) requests ALWAYS get built and triggers can't prevent that by excluding branches. As long as webhook exists for merge requests, they will get built.
For your issue ,the reason is:
Triggering on tags is not currently supported for Bitbucket Cloud
repos.
Please refer to the Note part of this official document. If you want tag trigger to work in yaml,you need to use another repo.
Have you tried this already?
trigger:
- refs/tags/*
Is there a way I can set up a build in Azure DevOps to automatically run every time a PR is merged and completed and contains a specific keyword in the name? for example: "Some PR name here [RUN_BUILD_123]"
Edit:
The reason for this is because I have different builds on top of the same branch so instead of triggering all the builds I just want to trigger those that I know need to be rebuilt based on the particular projects getting changed.
A PR has a target-branch. If you want to trigger a build after a PR is completed just configure a build with a ci-trigger for that target-branch. You can't check for certain keywords in the PR-name unfortunately
Agree with D.J. For detailed setting, you can check the Enable continous intergration option in the Triggers settings, then select the target branch you want ci-trigger build in the Branch filters.This will automatically trigger the build after pr is completed.
But you can't do it if you want to include special keywords in pr name.
Topic is a bit old, but if there is anyone who want's to archive this stumbling over this topic - here is my approach how I would solve this:
The basic of all are scripted pipelines, so if you still do it in the GUI - that's wasted time. Create a .yml build and put it into your Git. The M$ documentation is really helpful with this.
Create the trigger for your branch
Put this on the first line, so the pipeline will be executed when master (or your branch) has a new commit
trigger:
branches:
include:
- master
Read out the commit message via the VSTS variables
Trigger the builds, based on their ID via REST API (you can use the pipeline token for authentication)
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)