We use an internally hosted github server for our SCM, Jenkins for our CI and Git-Flow (via maven's jgitflow plugin) for our branching strategy.
I have a Jenkins build job set up such that it takes the git branch as a parameter and then can check-out and build the correct branch based on what was selected.
.....
.....
.....
What I would like - is to automatically trigger the BASE_JOB to build only the branch that's been pushed. So far, I have been unable to find any way to do this.
If I set up to build when changes are pushed to github, then the job will simply rebuild whatever the last built branch was regardless of the branch that's been pushed.
I've seen some plugins for Jenkins that will auto-generate template jobs when new branches are created - but I think it is over-kill to necessitate having a job per currently active branch.
Is there a way to pass a branch parameter to the "Build when a change is pushed to GitHub"? Or some other way to work around this apparent limitation?
Thanks!
Check with these settings and see if it works.
Related
I want to automatically merge commits from master into another parallel branch which is used for different deployment strategy. So essentially whenever there is a change in master I want that change to be merged into one more branch automatically.
Is there a way in Github UI to do so?
Github does support automerge, but only for Pull Request.
You might check out a GitHub Action like action-automerge
GitHub action to automatically merge the source branch into a target branch every time a change is made.
You can add a GitHub Action workflow to your project in order to enable that "action-automerge".
That being said, maybe you have other approaches which would be simpler than merging master/main. Using the same branch but with a deployment script able to detect its execution environment would be easier.
I am creating a new git workflow. And just like any other piece of code, I want to test it separately without having to merge it into master first.
This will also help if I have to make few corrections if something doesn't work in the workflow yaml.
Here is the mechanism that I am looking for:
main branch has .github folder which contains all workflows
I create a branch and add my workflow to .github folder
Now I should be able to see(somewhere on Github) workflows from my branch running
When I know that workflows are working fine, I merge my branch in master
Now under github 'Action' tab, new workflows will reflect
Is there a way to do this?
I am actually doing workflow testing all the name, as you can see this test workflow workflow-level-notification is not merged into master branch (ie default branch), and I can still see the workflows in the UI.
Like GuiFalourd said, you can also use act to do the local testing as well. But working directly in the github repo is not that bad. (you can delete the workflow after)
If you would like to test non PR triggerd actions you can simply update your default branch temporarially, run the actions for test, then when you are done switch back.
I'm looking for a solution to dynamically select a branch to build in the Azure pipeline. I have Azure Repos Git where I select project, repository and default branch. I would like to be able to select branch based on a variable.
What I'm trying now is to use the Command Line task and fire a git checkout command (e.g. branch is a variable):
git checkout $(branch)
I can't confirm it working yet but still I confirm it works but I feel that there is a better option than checking out default branch and then switching branch with the command line.
Update:
If you want to have single pipeline that can build different branches (version branches) for different branches, you could just specify them in the trigger of branch filters. This will not build all branches.
The branch you select in build definition is just the default branch used when you Queue New Build manually. OTOH the build trigger establish which branch to download, e.g. if the build has been triggered by a git push on branch develop then that is the one checkout'ed and built. Take a look at this link: Get the sources from the branch that triggered the build in Team Services
Besides, you could disable the default get source step.Then use you own powershell script and git command to get source code manually(just what you want) and check out branch, finally build based on your variable.
For YAML, to disable the default "Get Sources" just specify none in
the checkout:
checkout: none
For UI, please refer my reply in this question:
Is it able to ignore/disable the first step Get source in vNext Build?
Assuming you're choosing the default branch. That doesn't mean that
it's the only branch that can be built by that build definition.
You can choose which branches to monitor for CI (on the Triggers tab,
you can add multiple branch filters to represent the branches you wish
to build on commit), and the appropriate branch will be checked out
when the build is triggered. You can also choose an alternate branch
when manually queuing the build.
Source Link: Get Sources from multiple branches
If you want to dynamically select default branch as below, this is not available at present.
This is the branch that you want to be the default when you manually
queue this build. If you set a scheduled trigger for the build, this
is the branch from which your build will get the latest sources.
The default branch has no bearing when the build is triggered
through continuous integration (CI). Usually you'll set this to be
the same as the default branch of the repository (for example,
"master").
There is a related user voice here: When triggering a build, use the same branch as the trigger build. You could kindly vote up and track the process.
I've recently transitioned from XAML builds to v.Next builds. I've always kept one build definition per branch but I see the new system has the ability for a single build definition to trigger on multiple branches and pull requests.
Is this a good idea? What are things to watch out for and the best ways to set this up?
The first couple concerns that come to mind are:
1) Version numbers. How would I handle scenarios such as an old maintenance branch versioning as 1.0., master versioning as 2.0. and a dev build as say 0.2.* so I don't confuse build artifacts? Is there a better way?
2) What if the repos tree has changed? What if master expects to build a .sln in one folder but a dev branch has since moved it to another folder?
Any other concerns and resolutions?
Single build definition to trigger multiple branches and pull request can make VSTS build more flexible. You can choose the way as you need:
If you want to build a certain branch for a build definition, you can specify the certain branch name. Assume if you only want to build master branch, you can specify master branch in Get Source step (for manually build), or specify master branch in Branch filters (for CI build).
If you want to build multiple branches in a build definition (for CI build), you can specify the branches in branch filters on Triggers Tab.
If you want to verify a PR before merging, you can add build validation for branch policy.
For your concerns:
Even a build definition can trigger multiple branches, but for a certain build, it build a certain branch after changes are pushed on this branch. And you can detect which branch is actually build, and update branch version number correspondingly.
Such as you have a build definition which can trigger to build both for master branch and dev branch. After pushing changes to master branch, a build will be queued for master branch. And you can get the branch name by some ways, so you can increase the version number correspondingly.
You can not only specify which branches can be triggered in your build definition, but also specify the folders which can be triggered in path filters. Assume there are folderA and folderB both contain .sln, you want to trigger build only when the .sln file changes under folderA, so you can specify branch filters and path filters as below:
For the situation: multiple branches can be triggered by a build definition, you can add a PowerShell task to detect which branch is building. The script as below:
$head=$(git rev-parse HEAD)
$sha=$head.Substring(0,7)
$branches=$(git branch -rv)
for ($i=0;$i -lt $branches.Length; $i++)
{
if ($branches[$i] -match $sha)
{
$tbranch=$branches[$i] -split "\s+"
$local=$tbranch[1] -split '/'
$br=$local[1]
echo "You are building $br branch"
break
}
}
This part,
Is this a good idea? What are things to watch out for and the best ways to set this up?
is off-topic (too broad/primarily opinion based), so I'm ignoring it and answering the two concrete scenarios you outlined.
Not really sure what you're asking. Release definition environments can be set to trigger on branches (artifact triggers), so if you have different release requirements for older branches, you can have different release definitions or simply an alternate pipeline within a single release definition.
You can specify wildcards in the Visual Studio Build step so you can specify, for example, **/*.sln. That will find any .sln file under any folder.
We are using a private GitHub Organization as version control. When a task is assigned to a developer, they fork the primary repository, make their code changes, and submit a pull request to have the changes merged into the master branch of the primary repository.
We are also using TeamCity for CI. It is currently configured to kick off a build for a VCS commit, which builds, tests, and deploys the artifact to an artifact repository internally. To accomplish this, the Team City build configuration has multiple VCS roots installed; one for the primary and 1 for each developer's fork.
The problem is that Team City pulls from all of them when a commit is made assuming they are all necessary for the build instead of allowing you to only pull from the single repository that triggered the build. Any thoughts on how we can accomplish this without having to create n build configurations in Team City for each project (where n == number of developers working on a project)?
I see way to do this with preserving current workflow is turning off automatic checkout (VCS Checkout Mode), and checking out code manually in an additional command-line build step, with a parameter %teamcity.build.branch% (logical branch name).
I.e.:
git clone ...
git checkout %teamcity.build.branch%
Triggers will just start the job if there are changes in developer's VCS root, fulfill branch env variable; no automatic checkout will happen and then build step will check out only needed branch. Only works with one git URL.
After posting in the JetBrains forums, I was pointed to a blog that answers my question.
TL;DR: my approach of using feature branches does not work with GitHub's workflow. Instead, Forks and Pull Requests should be used. The blog referenced shows how you can use Team City to trigger off of a Pull Request. Simply add +:refs/pull/*/head to "Branch Specification" in your VCS Root and all pull requests to the Source repository will trigger your Build Configuration.