I want to have part of my destination path in build.cake be based on the branch being built. The top of my build.cake script says:
var branch = Argument("branch", "Master");
and I modified my Team City Build step to include
.\build.ps1 ... -Branch %teamcity.build.branch%
but Team City complains that I have no eligible agents
Implicit requirements: teamcity.build.branch defined in Build step:
Build
I'm new to TC and Cake so I'm likely missing something obvious. How do I hook this up?
You are correct that %teamcity.build.branch% will give access to your branch name. However, this variable is blank unless you have a branch specification in your VCS root settings. In order to use say master as your build.branch parameter you need to add: +:refs/heads/(master) to your branch specification. Whatever is in between the parens will be put in the build.branch variable. If you might be building from multiple branches, you might have something like the following:
+:refs/heads/Release/(765/1.0)
+:refs/heads/Release/*
This would give your build.branch the name of branch as it appears in git after the Release/.
Also see Johan's answer: https://stackoverflow.com/a/27829516/6222375
Related
I have a build configuration that runs on multiple branches. I would like to set a failure condition that compares code coverage numbers, but only within the current branch.
What i've done:
Added a build step that sets a custom parameter "CurrentBranch" to the value of the current branch (either %teamcity.build.branch% or %teamcity.pullRequest.target.branch% if its a PR build)
Added a build step that successfully adds a tag to the build (using the REST API) with the value of %CurrentBranch%.
Added a failure condition that compares the current code coverage with the last successful build with tag %CurrentBranch%
However, when I execute the build, I get a warning:
Invalid settings for build failure on metric
buildTag: Tag must be specified
If i explicitly set the tag in the "failure condition" properties to one of the branches, it works as expected.
Anyone know what I'm doing wrong?
I've also tried using the original %teamcity.build.branch% parameter. That did not produce the warning. So it seems to support parameters, but not parameters set during the build?
Edit: If I initialize my custom %CurrentBranch% parameter with %teamcity.build.branch% I no longer get the warning. Will need to check if (in the case of pull-requests) it actually uses the correct branch for metrics comparison.
The behavior still seems odd. If anyone can shine a little light on this, I'd be very thankful!
Let's say I have a branch called parent-branch and I create a branch right off of that branch by doing
git checkout -b child-branch parent-branch
That's all fine and well of course, but what I am looking (hoping) to do, is to be able to somehow reference parent-branch from within a bash script. So for example, something like git_current_branch and git_main_branch will print the current local branch I am in, and print the master branch, respectively.
Is there a way where I can do something like git_parent_branch (or something along those lines) to have access to the parent-branch in bash and the command line. Whether that be a bash script function, or whatever other potential possibilities might work.
Is there something involving GitHub and / or any associated APIs perhaps where this is possible. I'm not overly familiar with connecting to GitHub other than just using their web interface, so anything in that respect would most likely be of big help (ideally pertaining to my issue here)!
In Git at a fundamental level, branches simply don't have parents. Well, I say simply, but it's not that simple, because we haven't defined branch, and users of Git use the word very loosely and often mean different—and contradictory, sometimes—things when they say it. So let's define branch name first, which at least has a simple, definite meaning:
A branch name is a name whose full spelling starts with refs/heads/, which—in order to exist—contains the hash ID of some existing, valid commit.
The last bit here—which is kind of redundant: an existing commit is valid, and a valid commit (whatever that means) must exist—is a concession to the fact that we can have branch names that don't exist (yet, or any more): xyzzy, for instance, is fine as a branch name, but until you create it, it's just a sort of potential branch name, floating in limbo as it were.
Because a branch name must contain a commit ID to exist, a new, empty repository—which has no commits—has no branch names either. And yet you're on the initial branch. It's in limbo, as yet nonexistent. When you make your first commit in this empty repository, then the branch name actually exists. If you like, you can re-create this special case in a non-empty repository using git checkout --orphan or git switch --orphan. (These are subtly different in how they manipulate Git's index, but both put you in this funky state of being on a branch that does not yet exist.)
This kind of special case aside, because a branch name has to contain some commit hash ID, we normally create a branch by picking some existing hash ID, just as in your example:
git checkout -b child-branch parent-branch
But what Git does with this is to resolve the name parent-branch to a commit hash ID first, then create a new branch—in this case, named child-branch—containing that hash ID. The two branch names have no parent/child relationship; we could run git checkout -b daddy kid or git checkout -b xyzzy plugh and there's no parent/child relationships here either, despite the misleading name in the daddy kid version and the neutral names in the xyzzy plugh case.
Now we come to your own question, though:
Is there a way where I can do something like git_parent_branch (or something along those lines) to have access to the parent-branch in bash and the command line.
Git contains, as a useful tool—parts of Git make use of this in various ways—a fully general string-based configuration system, where we run git config to set some arbitrary string to some arbitrary value. By convention, these strings have a hierarchical structure: user.name and user.email live within the user space; push.default is composed of push + default; and so on. Git even stores them using an INI-file-style syntax.
What this means is that although Git itself has no parent/child relationship, you can make up your own. There are a few obvious drawbacks to doing so:
Git won't maintain it for you.
You need to choose names that Git won't clobber, even in some future release (Git version 3.14 perhaps).
Nobody else will understand what the heck you're doing.
So, if you choose to do this, you're on your own—but let's note that Git does store some per-branch information in the branch.name namespace:
branch.xyzzy.remote is the remote setting for the branch named xyzzy;
branch.xyzzy.rebase is the git pull setting controlling whether the second command to use is git merge or git rebase, and depending on which second command is to be used, what flags, if any, to pass to that second command, when you're on branch xyzzy and you run git pull;
branch.xyzzy.description is the descriptive text that git format-patch will include in a cover letter, when run for branch xyzzy;
and so on. So if you were to add a branch.name.parent string value, you could store your string here. You then merely need to hope that the Git developers don't steal that name—parent—from you in the future.
Since this stuff is totally free-form, you'd just run git symbolic-ref or similar to find the current branch name, then git config --get branch.$branch.parent to get its parent setting, if it has one. If it does not have one, this must be a normal everyday parentless Git branch, rather than one of your own specially decorated branches that does have a nominal parent. To set the parent for some branch, you'd run git config branch.$branch.parent $parent, where $parent is the setting you want. (It's your decision as to whether $parent is required to be a branch name, in which case strings like xyzzy and main and plugh are fine, or whether it could be a remote-tracking name as well, in which case, you'd better use fully-qualified strings like refs/heads/xyzzy, refs/heads/main, and so forth. That will allow you to use refs/remotes/origin/main—a remote-tracking name—as a "parent".)
Is there something involving GitHub and / or any associated APIs perhaps where this is possible.
Definitely not, and this points up another weakness in the idea of using branch.$name.parent: there is no way to record this data on GitHub. It's a purely local setting. Then again, branch names are purely local: there's noting that requires that you call your development branch dev or develop, even if the development branch name in some GitHub repository you've cloned is called dev or develop.
Before I finish this off, let me add another several definitions of branch. We'll needs a few more definitions as well:
A branch tip is the commit to which a branch name points. That is, given some branch name like main that indicates some particular commit hash ID such as a123456..., the tip commit of branch main is a123456.... Checking out a branch by its name—with git checkout or git switch—and then adding a commit automatically stores the new commit's hash ID in the branch name, so that the tip commit automatically advances. The new commit's parent will be the old branch tip.
A branch (in one of its many meanings) is a set of commits that includes the tip commit of a branch (with branch here meaning name that contains a commit hash ID). Where this set of commits begins is in the mind of the user, but if left unspecified, Git generally includes every commit reachable from the tip commit.
To define reachable, see Think Like (a) Git.
A remote-tracking name is a name that exists in your Git repository but was created due to a branch name that your Git saw in some other Git repository. These names live in the refs/remotes/ namespace, which is further qualified by the remote, such as origin. For instance, refs/remotes/origin/main would be a remote-tracking name in your repository, in which your Git remembers the hash ID stored in origin's branch name main, the last time your Git got an update from their Git.
For some users, a remote branch is a branch (in the meaning of series of commits terminating at a tip commit) where the tip commit is given by a remote-tracking name. For other users—or the same user speaking at some other time—a remote branch is a branch that exists in some remote repository, such as origin. These two are easily conflated since your own origin/main tracks the other Git's main, hence the term remote-tracking name. (Git calls this a remote-tracking branch name, but the adjective remote-tracking in front of the noun name seems sufficient here.)
As you can see, the word branch is so loosely defined as to be nearly valueless. We can often reconstruct the correct definition—the one a speaker or writer had in mind—based on context, but for clarity, it's often better to use some other term.
I'm trying to push head commit to remote with WIP- showing error like
$ git push remote 51447424149c671958a2f76ec1fefb135a5c2cea:WIP-51447424149c671958a2f76ec1fefb135a5c2cea
[which results in]
error: unable to push to unqualified destination: WIP-51447424149c671958a2f76ec1fefb135a5c2cea
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'https://github.com/abc'
Any help ?
TL;DR
You probably wanted:
$ git push remote 51447424149c671958a2f76ec1fefb135a5c2cea:refs/heads/WIP-51447424149c671958a2f76ec1fefb135a5c2cea
to create a branch named WIP-51447424149c671958a2f76ec1fefb135a5c2cea. (Be sure you really want to create that name, as it's kind of unweildy. It's valid and there is no problem with it, it's just a heck of a thing to type in.)
Long
What Git is complaining about takes a little bit of explanation:
A branch name is a special form of reference.
A reference is a string starting with refs/. The familiar two kinds of references are branch names and tags. (More about this in just a moment.)
References can be abbreviated ... sometimes, but not always.
Sometimes (wherever it makes sense to Git) you can use a raw hash ID instead of a reference.
git push takes a refspec, which is a pair of references separated by a colon (and optionally the whole thing can be prefixed with a plus sign).
What you're doing with git push is using the (very long) refspec 51447424149c671958a2f76ec1fefb135a5c2cea:WIP-51447424149c671958a2f76ec1fefb135a5c2cea. The left side of this refspec is the source reference, and the right side is the destination reference.
The thing on the left side of the colon is clearly1 a hash ID. So this is making use of the special case where you can supply a hash ID instead of an actual reference (as long as that object actually exists in your Git repository).
The thing on the right side of the colon, though, is a name, not a hash ID. This is good since this is one of the places that Git requires a name. But it's also a problem, because the name WIP-something does not start with refs/.
Note that Git explicitly complains about that:
The destination ... nor begins with refs/
Before we get to the rest, let's mention branches and tags again. A branch name like master is short-hand for the reference refs/heads/master. A tag name like v1.2 is short-hand for the reference refs/tags/v1.2. Note that in both cases, these start with refs/. They go on to name which kind of reference we're using:
A branch name reference starts with refs/heads/.
A tag name reference starts with refs/tags/.
In other words, when we say that branches and tags are forms of references, we're saying that given a reference, you can look at what comes right after refs/ and figure out what kind of reference it is: refs/heads/ means "branch" and refs/tags/ means "tag". (If you see refs/remotes/, that means it's a remote-tracking name; and there are yet more special words that go after refs/, such as notes/ for git notes.)
We also said above that references can sometimes be abbreviated. That's the first part of what Git is complaining about here, though:
... neither matches an existing ref on the remote ...
You're allowed to leave out the refs/heads/ part, and have the other Git—the one that your Git is pushing-to—figure out that master really means refs/heads/master. But this only works if they already have a refs/heads/master. If you're trying to create a new branch, you must tell the other Git: I'd like you to create a new branch.
You do this by giving the full name of the reference: refs/heads/WIP-something, for instance. The fact that it starts with refs/heads/ tells the other Git: I'd like to create a branch name. If you send them refs/tags/WIP-something, you are telling them to create a new tag name.
Anyway, this is why you're getting the rather long complaint, with its two parts: "neither ... nor". So the solution is to send them the full name.
1What, isn't it obvious? :-) This reminds me of the professors who prove theorems by doing six transformations and then saying "the rest is obvious...".
Git 2.21 (Q1 2019, 1 year later) will improve that error message: "git push $there $src:$dst" rejects when $dst is not a fully qualified refname and not clear what the end user meant.
The codepath has been taught to give a clearer error message, and also guess where the push should go by taking the type of the pushed object into account (e.g. a tag object would want to go under refs/tags/).
Note: DWIM (used below) is "do what I mean":
computer systems attempt to anticipate what users intend to do, correcting trivial errors automatically rather than blindly executing users' explicit but potentially incorrect inputs.
See commit 2219c09, commit bf70636, commit dd8dd30, commit 04d1728, commit c83cca3, commit 8b0e542, commit cab5398 (13 Nov 2018) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 0a84724, 04 Jan 2019)
push: improve the error shown on unqualified <dst> push
Improve the error message added in f8aae12 ("push: allow
unqualified dest refspecs to DWIM", 2008-04-23, Git v1.5.5.2), which before this
change looks like this:
$ git push avar v2.19.0^{commit}:newbranch -n
error: unable to push to unqualified destination: newbranch
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git#github.com:avar/git.git'
This message needed to be read very carefully to spot how to fix the error, i.e. to push to refs/heads/newbranch.
Now the message will look like this instead:
$ ./git-push avar v2.19.0^{commit}:newbranch -n
error: The destination you provided is not a full refname (i.e.,
starting with "refs/"). We tried to guess what you meant by:
- Looking for a ref that matches 'newbranch' on the remote side.
- Checking if the <src> being pushed ('v2.19.0^{commit}')
is a ref in "refs/{heads,tags}/". If so we add a corresponding
refs/{heads,tags}/ prefix on the remote side.
Neither worked, so we gave up. You must fully qualify the ref.
error: failed to push some refs to 'git#github.com:avar/git.git'
This improvement is the result of on-list discussion in the thread "Re: [PATCH 2/2] push: add an advice on unqualified <dst> push" comment #1 (Oct. 2018) and comment #2, as well as my own fixes / reformatting / phrasing on top.
The suggestion by Jeff on-list was to make that second bullet point "Looking at the refname of the local source.".
The version being added here is more verbose, but also more accurate.
Saying "local source" could refer to any ref in the local refstore, including something in refs/remotes/*. A later change will teach guess_ref() to infer a ref
type from remote-tracking refs, so let's not confuse the two.
And that is not all: there is a new setting now.
Now with advice.pushUnqualifiedRefName=true (on by default) we show a
hint about how to proceed:
$ ./git-push avar v2.19.0^{commit}:newbranch -n
error: The destination you provided is not a full refname (i.e.,
starting with "refs/"). We tried to guess what you meant by:
- Looking for a ref that matches 'newbranch' on the remote side.
- Checking if the <src> being pushed ('v2.19.0^{commit}')
is a ref in "refs/{heads,tags}/". If so we add a corresponding
refs/{heads,tags}/ prefix on the remote side.
Neither worked, so we gave up. You must fully qualify the ref.
hint: The <src> part of the refspec is a commit object.
hint: Did you mean to create a new branch by pushing to
hint: 'v2.19.0^{commit}:refs/heads/newbranch'?
error: failed to push some refs to 'git#github.com:avar/git.git'
When trying to push a tag, tree or a blob we suggest that perhaps the user meant to push them to refs/tags/ instead.
The config has a new advice:
pushUnqualifiedRefname:
Shown when git push gives up trying to guess based on the source and destination refs what remote ref namespace the source belongs in, but where we can still suggest that the user push to either refs/heads/* or refs/tags/* based on the type of the source object.
Is it possible to add comments into the Artifact paths field in Team City? What format should I use? I'd like for the next guy to be able to quickly understand what is going on and why.
You can use anything that doesn't match a file. It will show up as warning in the build log (matching artifacts not found), but do no harm otherwise.
I use a hash to start comments, for example:
# Collect all DLLs from unicorn
unicorn/**/*.dll
I'm getting a Target branch empty drop-down list, on TFS:
Source branch:
$/ProjectName/TEST/ApplicationName
Target branch:
empty drop-down list, should have a "$/ProjectName/PROD/ApplicationName" option
No idea why... The branch I want to merge to, exists...
I appreciate any tips to ensure the branch shows up on the drop down list. Thank you!
Sorry... I was doing a Merge, when i needed to Branch!
Source branch: $/ProjectName/TEST/ApplicationName
Target branch name: textbox, typing value "$/ProjectName/PROD/ApplicationName"
I was able to promote from the TEST to the PROD branch now.
For the first promotion from TEST to PROD, I'm using a Branch, for the next ones, I'll use a Merge. (I'll post screenshots as soon as possible to show the dialogs.)