I only have a develop branch in my repository at the moment.
When I try to create a project from it in Teamcity, I get the following error message:
Cannot find revision of the default branch 'refs/heads/master' of vcs root 'dummy VCS root (jetbrains.git)'
The question i:s how can I create a TeamCity build from repo without master branch? In Jenkins usually it makes no problem to build any branch
open attached VCS Roots of your project
Change Default branch to refs/heads/develop
Branch specification set to +:refs/heads/*
Now your default branch is develop, not a master.
Also, you able to see all branches because of the Branch specification
Related
I finished an Xcode project and pushed it to github from Xcode 'Source Control' Menu. Then I changed the project name CountryBook to Countries. I Built project and ran. Everything was okay. Then I coiped project folder to desktop as a backup. Then pushed project again. Everything has messed up. Some old named folders and files still exist in repo. Then I deleted every directory and file from github repository. Now, backup version of project is working. But when I try to push it to repo, old files are still exist. I deleted 'origin' from 'Remotes' and created a new repo named 'Countries'. I pushed project again but it was same. A mixed version of old files and new files. When I clone the github version of project, of course it is not runnable. What sould I do and how can I push clean version of my project? I don't want to lose project.
This is Countries repo now:
This is my working project folder with correct content:
I would fix it via command line, lets assume you start from scratch:
Step 1 - prepare the working branch:
Clone the project
Navigate to root folder of the project
Checkout the main branch ("main", "master", or whatever it is)
Create a new branch you will be working with
git clone https://github.com/yourorg/yourrepo
cd yourrepo
git checkout main # or master
git checkout -b fixprojectstructure # branch name can be anything
Step 2 - clean project locally
Delete old project, old workspace, ensure the names in Podfile and Podfile.lock are fine
Build the project and ensure it's working
Step 3 - commit your changes:
# assuming you are in the root of the project
git add .
git commit -m "Some explanation"
Step 4 - push your changes:
I usually do it the lazy way: just run git push, which will show you the proper syntax to push remotely, something like
> git push
fatal: The current branch fixprojectstructure has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin fixprojectstructure
> git push --set-upstream origin fixprojectstructure
Enumerating objects: ...
...
remote: Create a pull request for 'fixprojectstructure' on GitHub by visiting:
remote: https://github.com/.../pull/new/fixprojectstructure
remote:
...
Branch 'fixprojectstructure' set up to track remote branch 'fixprojectstructure' from 'origin'.
Step 5 - merge your changes:
Basically just do what the line above is saying:
Navigate to https://github.com/.../pull/new/fixprojectstructure
Create pull request
Merge pull request to main (or whatever the initial branch was)
Note on the side: configure the gitignore file properly for your repo as well. For starters, follow the gitignore template to create a proper gitignore file, and then change it the way you need to.
For instance:
Usually, if you use cocoapods, you do not store .workspace folder and its contents in the repo. Instead it's generated using pod install command on each machine that needs it.
It's also common to exclude Pods directory from storing in the repo, although there are pro / cons arguments both ways.
Given I have Teamcity job with Git VCS root with default branch which can be changed with branch-name parameter:
When I e.g. set branch-name to develop in admin screen, go back to build configuration home and run custom build where I change branch-name parameter to master
then I get:
Why is that?
What should I change, so that I don't get this message and I can change branch when running custom build?
The reason for this is I want to build and deploy software artifacts from any feature branch
the Teamcity has an opportunity for monitoring the branches and runs built to custom branch.
Firstly, edit your VCS Root and add follows:
Default branch: refs/heads/master
Branch specification:+:refs/heads/*
now the TC will check changes by some interval.
We are sets the master as default branch. and when we run the build with default parameters, the build will start to master branch
If you are want to start build with custom branch then press Run... -> Changes -> select your custom branch from Build Branch parameter.
If you want to run build from API, or want to reverse the build branch parameter, just set Configuration parameters with key teamcity.build.branch
and value what you want
I have a build configuration that builds following tags "develop", "master" and "hotfix" from my branches.
The problem is my branches are not called hotfix in git. They are called for example "hotfix/v1.1.5".
To change that I use the "Shorten Branch Name" feature from TeamCity. I have to do following in the VCS Root to get what I need:
+:refs/heads/(hotfix)/v1.1.5
You maybe can already see the problem. I have to do this for every new hotfix. Is there a way to get TeamCity to build all hotfix branches under the tag "hotfix"?
I tried this but it is not working.
+:refs/heads/(hotfix)/*
Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:
The build configuration in Teamcity must use the build format number
%build.vcs.number% you will also want to configure monitoring of all
branches so merge requests build, that setting is in the vsc root
advanced settings.
I'm not sure how this works. Lets say I have a repository Foo.
I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge
I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.
But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).
I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.
So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.
I'm currently running GitLab 7.9 and TeamCity 8.1.4
Update:
Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240
I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.
I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.
I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)
Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.
Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.
Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:
IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git#your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git#your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>
As stated here [1], GitLab-CE can fire an event on creation of a merge-request,
so all you have to do is building some meta, that can evaluate the WebHooks.
[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events
I have a TeamCity setup with two projects building different svn branches from the same repository.
First project is for the trunk (stable), and other is for my development branch.
Whenever I commit something to my branch, trunk build is triggered.
Is that normal and can it be avoided?
I'm using TeamCity 6.0.
Marco, are you absolutely sure that your VCS settings for the trunk project do not include sources from the branch?
You configuration should be something like:
svn://server/root (VCS root)
trunk => . (checkout rules for trunk build)
branch/dev => . (checkout rules for branch build)
In this case, everything should work as expected.
Another thing - if your trunk and branch reference the same SVN external, and there is a change in this external, both builds will be triggered.
You can specify your trigger, e.g. the trigger pattern! Or you can write a custom build trigger :-).
Pattern for the trigger pattern :
+|-:[user][VCS root][path]