Is there a way to get a link to a bitbucket hosted repo to show up in a TeamCity build? The build knows which VCS root the commit came from as well as the commit hash, I just can't find a way to get that to display as a clickable link in the build.
You can use repo URL as VCS root's name and it will be visible on Changes tab of the build.
But more general, why would you need the link to bitbucket? There is a perfect change log and diff-viewer right inside TeamCity web UI.
With some finangling, you can set up an external change viewer. Documentation is here: https://confluence.jetbrains.com/display/TCD10/External+Changes+Viewer
Unfortunately, you'll need to use the "build-specific" syntax as there's no project/repo-agnostic URL that you can feed to bitbucket. Here's an example:
ProjectName_BuildName.changeSetUrl=https://bitbucket.example.com/projects/MYPROJECT/repos/my-repo/commits/${changeSetDisplayRevision}
ProjectName_Buildname is really the "Build configuration ID" that you set (or use the suggestion).
Related
The fork option is greyed out for me I have developer access what do I do?
I’m told for importing to github to look for the project url e.g
I also don't see that button in the first image do I have to fork first? Also, if so do pulls using github desktop automatically pull to the main branch in gitlab, or do I need to pull in gitlab as well.
What is the least technical way of using gitlab?
The fork option in your project probably been disabled. This setting can be changed in the Project:
Settings -> General -> Visibility, project features, permissions
However you need to be a Maintainer or above.
If you want to import a GitLab project to GitHub, see Transfer git repositories from GitLab to GitHub - can we, how to and pitfalls (if any)?
I'm using GitKraken (v. 1.4.1) as my Git managing tool. And now I want to use Github as a remote to back up my repos. But when I click on add remote and try to add a Github repo, it just says 'no match'
Does anybody know why this happens? (BTW: I'm using Windows 10, just in case that's relevant)
Here's how it seems to work. If you have a local repo and want to connect it to github, you would use the "URL" option and put in the github address to set that as the remote repo for your local repo. The first time you do a pull or push on a local branch, it will ask which remote branch you want to use and that becomes the remote location to which you will pushing and pulling changes.
The GitHub.com option only comes into play after you have set the remote repo using the "URL" option. If there are multiple collaborators on a project and someone has created one or more forks of the project, then instead of "No Match" under the GitHub.com, you would see a list of all the forks of the project on which you are a collaborator.
You could then add the forked repos as the 2nd, 3rd, etc. remotes, and any activity on those forks would be displayed to you on the commit graph. This allows people to see what's going on in the forks, and you can drag and drop from the forked parts of the graph to create pull requests to the repo you first set up using "URL".
It's a nice feature, but the remote dialog could be labelled more clearly so that people would know the GitHub.com option was for adding forked repos to the commit graph display.
You must always use the "URL" option to add the 1st remote, and then the GitHub.com option only becomes available after that if there are forks to which you have access.
If GitHub is set with your account in GitKraken, you might need to create first an empty repo with the same name as your local repo.
That way, GitKraken can find a matching repo name in your GitHub account.
Or you could select "URL", and enter the right GitHub repo url directly there. Which is what Jim Meyer's answer confirms above.
Note that GitKraken 6.5 (January 2020) will create, then add a GitHub fork repo automatically!
Forking GitHub Repositories in GitKraken
Formerly, users were required to leave GitKraken, go to their hosting service, fork the desired repository, come back to GitKraken, find the related remote, and then find the forked repo. 😅
Now, GitHub users can fork repositories directly through the GitKraken GUI, no more time wasted context switching.
v6.5 allows users the ability to fork GitHub repositories in GitKraken through the GitHub integration.
Simply navigate to the remotes pane in the left panel and click the + button to add a remote.
If you don’t already have a fork on the selected GitHub repository, GitKraken will automatically present you with the fork option.
You will see the message “You have not yet forked microsoft/vscode on GitHub.”
Click the Fork and Add Remote button, and it will fork the repo and add it as a remote to the left panel.
Gitkraken (V3.3.4 64bits on windows) behaviour is strange at this feature level. Same name or URL input doesn't work for me.
So the best and quick way to attach the remote repo to your local is to use the simple Git command line in local repo directory (git#... is your remote URL Github, GitLab...):
> git remote add origin git#...
Gitkraken recognise dynamically it after less than 5 second . Then you can push your existing local files.
Not to add to an old posting but I had the same issue and found this article first so wanted to help anyone else having this issue.
You can get to it by doing the following.
Click the folder icon in the top left corner
Click Clone
Go to the GitHub tab and you will see all your GitHub repos. Clone the one you want and then open it and you are set.
About a week ago Git support was added to Visual Studio 2012 and Team Foundation Service. I've been playing around with it a bit and wanted to publish a local repository to my team project. It's described in step 2 on the Team Foundation Service website:
Publish your local Git repository into your new team project.
Now I've been doing the exact same thing, but I don't get the "Publish to ..." context item. Could this be a bug or am I missing something?
I was having the same problem. I don't know why.
However, after a bit of playing around, I managed to get the following
working. Disclaimer: can't guarantee this is actually the correct way
to do it. It may bork things further. And whether it does the same as what the missing 'Publish' menu item is supposed to do, I have no idea. Use at your discretion...
Get the url of your git repo in the project you set up in TFS.
Go to your project in the TFS web interface, then Code tab.
You should get a message that gives you the URL.
e.g. https://user.visualstudio.com/DefaultCollection/_git/YourProject
Edit the .git/config file on your local repo.
Configure the origin remote to point to your TFS repo.
(note: if you already had an origin remote, you might want to rename that first to keep it)
e.g.
[remote "origin"]
url = https://user.visualstudio.com/DefaultCollection/_git/YourRepo
fetch = +refs/heads/*:refs/remotes/origin/*
Open your solution in Visual Studio.
Edit a file.
Do a commit.
Do a push.
This should hopefully push your local repo to your TFS remote as origin.
From here things seem to be working for me -- the code is up in my TFS
web interface at least, and I can push commits to it. I can add backlog items etc. I'm new to TFS though so not sure if it's actually all working as it should be.
I was just having the same problem, and the answer by ngm didn't work; I had to do the opposite. The [remote "origin"] section was already in my .git/config file, however the project code wasn't uploaded to TFS.
To fix it I just deleted that section from the config file, then restarted Visual Studio and followed the official instructions.
I had this same exact problem. I was able to resolve it by restarting Visual Studio completely, opening Team Explorer, then navigating to my local repo. I opened up my local .sln, then clicked on "Changes", "Commits" and it then had an area where I could Publish the project to a URL. I took that URL such as: https://myapps.visualstudio.com/DefaultCollection/_git/MySolution and then clicked "Publish" (I had to do it twice.) I can now commit to the TFS and view my code online.
I had the same issue. I had to delete all of my remotes in .git/config (not just origin) before the Publish option is available. Apparently, Microsoft assumes you would never even dream of using a different remote.
I found it helped to start a new solution and publish from there going step by step.
Once it's 'confused' itself it's best to start the process over. I got it working and never had to edit that file.
I tried all of the above but the only way I could get it to work was to use git hub for windows.
To make that work you will need to set up alternate credentials. https://tfs.visualstudio.com/en-us/home/news/2012/aug-27/
For submitting an existing local repository to TFS-Git:
Create new project in TFS.
Using Git Extensions, select the local
repository that you want to push to your new project in TFS.
Select the push arrow.
Select Manage remotes.
In URL, enter the location of your TFS project: https://[your site
name].visualstudio.com/DefaultCollection/_git/[Your project name]
Save. Do you want to automatically configure push and pull? (I said yes.)
Close.
Select dropdown box for Remote - select the Remote URL you just
saved.
Push.
While setting up my account at TFS, I did set up an alternate credentials, though I am not sure if they were needed for this process.
I am new to GIT and TFS, but this process allowed my to push two of my solutions, each with three projects into TFS. Also, within Git Extensions, I found that I could organize my local repositories into categories, which proved a convenient way to organize my projects into their solutions. I would like to do the same in TFS, too.
I had the same problem today, I was not understanding why this "Publish to..." menu didn't appear.
I found that it's because you have to map one online repository to a local one, no more.
In your example, it seems Gittyup online is already mapped to Gittyup local, so you have to create a new Git project in the web interface, then you connect to it in VS, and then you can publish your local repository to the online one.
In the Team Explorer window find your repository under Local Git Repositories. Right click on the one you want to change and pick Open Command Prompt.
Now type git remote -v and it should show you the remote name and the complete url for it.
type git remote remove origin assuming origin is the name of your remote repository. Then git remote add origin [url] replacing [url] with the actual url of your repository.
Now you should be able to push your master branch into the repository for your team project.
I can confirm other answers, that the GIT repo cannot have any remotes listed or VS13 won't add it to the team project. I was using Atlassian tools Stash / Bitbucket / SourceTree and as soon as I closed VS13, removed all the remotes, reopenened VS13, opened the team project, and right clicked on my local GIT repo. The option "Publish to {teamProject}" was available and the .sln was then available by opening the team project.
Same problem here, except instead of editing git config files, just delete the entire git repository folder for the project. Reload the project and start over with Source Code action under file. Then add all changes to the project to the local Git. Then "Sync" and it will display the url textbox.
Create the project in VSTS/GitHub/somewhere, then from Git Bash...
git remote add origin https://xxx.somewhere.com/_git/xxxProjectNamexxx
git push -u origin --all
I've got a CI build pulling feature branches from Github and building/packaging them into a local folder, using a folder naming convention based on the project, branch and build number.
For named branches (feature1, feature2) this is working great.
The problem is that when I do a commit to the master, TeamCity exposes teamcity.build.branch as <default> - which means when the build step expands
E:\Packages\MyProject\%teamcity.build.branch%\
it's ending up with E:\Packages\MyProject\<default> - which is then crashing the build step because it isn't a valid Windows path.
I can see the master branch name in the fully-qualified build parameter:
teamcity.build.branch <default>
teamcity.build.checkoutDir C:\TeamCity\BuildAgents\agent-mulder\work\2151838a7933464d
teamcity.build.default.checkoutDir 2151838a7933464d
teamcity.build.id 16347
teamcity.build.vcs.branch.github_myproject refs/heads/master
but ideally I need to get master as the teamcity.build.branch for use in my build steps.
Can I transform the parameter at runtime? Override the behaviour? I've even tried setting the VCS branch name to DO_NOT_USE in the hope that "master" would no longer match the default - but this doesn't appear to work either.
In teamcity 7 its simply %vcsroot.branch%
that returns develop.
In my case I have
%MajorVersion%.%MinorVersion%.%PatchVersion%-%vcsroot.branch%
Which are all set in build parameters.
The number format is %BuildFormatSemVer% which is the stuff above and . {0}
%BuildFormatSemVer%.{0}
Which returns
#1.0.0-develop.4
Not ideal, but I was able to work around it by creating a new branch in git named "teamcity" and setting that as the default branch in TeamCity, it seems to require that the branch actually exist, since it worked when I created the branch, but didn't when you just entered a fake name.
Hopefully they actually fix this, because this is definitely a hack.
We have run into this problem several times when creating pipelines. It is the most visible when trying to automatically build feature and release branches using the Gitflow workflow. What we've been able to do was to use teamcity.build.vcs.branch.github_myproject and a regular expression in sed to sanitize the string whenever we wish to use it. This is mainly to watermark artifacts for debugging purposes.
The larger issue, at least for us, is that the TeamCity 7.1.1 version does not automatically fire off dependency builds for anything that isn't the default build in the VCS root. Obviously this is a huge pain point as we're now going to have to click manually in the tool. We haven't yet figured out a clean way to get around this other than hooks in git which use the HTTP API to call out to the proper build step.
I don't know if this was previously answered, or is any longer relevant.
In TeamCity 10.0.2 create a custom parameter such as %Git.Reference%. If you require a pull (or push) from TC to git, set this to "ref/head/Dev" or "ref/Head/yourbranch". Use this in your 'VCS root' reference.
I'm dumb with continuous integration and noticed a behavior that does not seem right..
I'm using Mercurial with TeamCity. When I push changes the TeamCity detect the changes but don't run the build automatically. This is correct behavior? He should not detect the changes and run the build automatically?
Triggers are not added to build configurations by default in TeamCity. You'll need to go to the settings for the configuration and click on "Build Triggers" then "Add Trigger". The type of trigger I believe you are looking for is a "VCS Trigger".
The documentation for this feature can be found here.
I believe my issues was misunderstanding what was needed in Branch Filters. I thought I was supposed to enter the GIT refs I wanted to have builds triggered from
This wasn't working for me
+:refs/heads/*
-:refs/heads/releases/6.7.3
-:refs/heads/releases/6.8.30
-:refs/heads/releases/6.8.32
-:refs/heads/releases/6.8.34
And this is what finally figured out (I think) is that it is asking for the branch names inside TeamCity itself (the help text says "Newline-delimited set of rules in the form of +|-:logical branch name")
This worked for me, to trigger builds from the branch (GIT ref refs/heads/master for me, look back in your VCS Root setup) and all other branches except those labeled "releases/6.7.3", "releases/6.8.30", "releases/6.8.32" and "releases/6.8.34"
+:*
-:releases/6.7.3
-:releases/6.8.30
-:releases/6.8.32
-:releases/6.8.34