I have problem with Extra sync option on TeamCity.
On page Edit VCS Root I am specifying Label/changelist to sync: with change list number for example 900001 and in field 'Extra sync options:' also added some changes that I want to apply 900002.
In log I see message
[Updating sources for root 'Current1.02', revision/label: #900001] Running 'p4 sync -f //depot/.../.../.../MainView.cpp#900002' in directory C:\BuildFolder\Desktop
In result i have .exe without any signs of changes that was submitted in 900002.
Why it does not apply those change? Where can be problem?
I'm not familiar with this plugin, but if it's running this command:
p4 sync -f //depot/.../.../.../MainView.cpp#900002
it might be hitting problems with too many embedded wildcards.
Related
I am using git in cli to change the current branch:
git checkout dev
and it produces:
fatal: cannot create directory at 'app/src/androidTest/java?com': Illegal byte sequence
As answered in this question and this one, I tried:
LC_ALL=C git checkout dev
or
LC_CTYPE=C git checkout dev
but I am getting the same error as shown above.
Running:
git status
shows that some of the files were changed by the checkout, but I am still on the master branch.
How can I remove the file causing the problems or how can I checkout the branch without getting this error?
The locale only affects how things are displayed. If the file name contains a character which isn't allowed by the file system, no amount of locale tweaking can fix that.
I can't think of a way to force a file system to let you create a file which then cannot be used, or a good reason to want to be able to do that.
Probably as a workaround, create a virtualized host with a bare-bones Linux system formatted to permit old-style 8-bit file names (Latin-1 or CP1252 if you can live with the unsavory Windows flavor of that), check out the file there, rename and commit the rename back to git. You still won't be able to check out versions of the source tree from before the rename.
I have found a few files in various github projects that are not compatible with one or another operating system. Files with a ".nul" or ".con" extension are a real pain on windows, for example. It isn't a problem exclusive to git. For example Subversion will abort nastily if it can't restore a file for local naming reasons.
In some cases the file may have been uploaded in error. If that is the case for your own projects it should be possible to use the git tools to list the archive and perform a delete of the file from the archive without actually instancing the file locally.
In other cases perhaps that particular file is not significant, and perhaps can be ignored. Perhaps a test will fail if it is missing?
One trick I have used is to stop the whole folder containing that file from being synced by manually creating the directory path, but for the last element, create an empty file instead of a folder. Of course, now the whole test suite will fail.
When the version control tries to do the checkout, it will simply fail to restore the folder, rather than giving a fatal error.
Of course, that only works if the folder is non-critical, e.g. some test files.
The alternative is to piecemeal check-out all but the problem file, but that can be a tedious sequence of checkouts. But you can use this attack to restore the rest of the folder that you omitted using the above technique. Alternatively, locally drag the files from the zip download if they are non-critical.
Our application uses VSTS for our CI flow and we have a requirement that the patch version should increase by one each time code is merged back into master.
We have created a shell script that will bump the version of the application and tag the repo, but now we are looking for the best place in the flow to inject it. We've thought of the following:
Master commit hook build - The problem with putting this here is that we have protected the master branch with certain policies (must resolve all comments, project must build, etc). Because of this, the build agent runs the script does not have access to push changes.
Pull Request build - This option would integrate the script into the build job that is used to verify the build. This actually works, but when the updates are pushed to the branch, this triggers an infinite build loop because the PR automatically rebuilds the branch. In general, this option seems more brittle.
I would love to have option 1 work out, but despite all attempts to grant the agent proper roles, it still does not have access to the repo. We're getting the following error:
TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.
Is there a standard way to do this that I'm missing?
To update the file version and add tag for the new commit through CI build, you can add a PowerShell task. detail steps as below:
Set permission and configure in build definition
First go to Version control Tab, allow below items for Build Service:
Branch creation: Allow
Contribute: Allow
Read: Inherited allow
Tag creation: Inherited allow
Then in your build definition, add the variable system.prefergit as true in Variable Tab, and enable Allow script to access OAuth token in Options Tab.
More details, you can refer Run Git commands in a script.
Add powershell script
git -c http.extraheader="AUTHORIZATION: bearer %SYSTEM_ACCESSTOKEN%" fetch
git checkout master
# Get the line of the file that contain the version
# split the line, and only get the version number major.minor.patch.
# check the version numbers (such as if patch less than 9) and increase the version
#replace the old version with new version in the file
git add .
git commit -m 'change the version as $newVersion'
git tag $newVersion
git push origin master --tags
Note: Even the new version and tag can push to remote repo successful, the PowerShell task may failed. So you should set the task after PowerShell task with custom option as Even if a previous task has failed.
You can try to update your branch policy per documentation on https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops and https://learn.microsoft.com/en-us/azure/devops/organizations/security/permissions?view=azure-devops#git-repository-object-level
Try updating your branch policy with to "Allow" "Bypass policies when pushing"
I've recently set up a Bazaar repo on my FTP server (only access I have to back end, please don't go into reasons why I shouldn't use FTP).
I have managed to get everything working with short cuts such that I can include user and pass in the ftp URL:
ftp://"user":pass#host/path
Though I am trying to set up script that I can commit from a local directory with a batch file. The issue is I still require to put in the password everytime.
bzr commit "E:\Ryan - Backup\Other\test" -m batched
I had a crack at using the authentication.conf file but it either didn't work for me in this situation or I was doing it wrong. I placed the file in the .bzr folder so it was located at:
E:\Ryan - Backup\Other\Test\.bzr\authentication.conf
With the contents being:
# Identity on foo.net
[site]
scheme=ftp
host=site
user=username
password=pass
Am I doing something wrong or would I have to create a plugin to do what I am after.
P.S End result was to run a batch at startup and shut down so I could sync file updates between my computers.
UPDATE: I also tried the
guide that describes the location of:
C:\Users\rfleming\AppData\Roaming\bazaar\2.0
for the authetication.conf file, this didn't work either
UPDATE 2: Placing the authentication.conf into the:
C:\Users\rfleming\AppData\Roaming\bazaar\2.0
Worked fine and I just ended up using checkout and push for syncing and no manually password typing was required!
Is it possible to get the raw build log from a TeamCity build? I've written a custom test runner that gets run as a commandline build step and reports test results back by printing ##teamcity... lines to stdout. The build log from TeamCity seems to be stripping these out when it recognises them. I'd like to see the raw output to help debug my test runner.
Update:
Apparently this simply isn't possible. neverov (I assume Dimitry Neverov of JetBrains?) has explained this and given a workaround so I've accepted his answer.
You can see the raw output from the build agent by looking in the agents /logs directory. This shows the unparsed data that is being hidden on the build output shown in the TeamCity console.
For example c:\TeamCity-Agent\logs\teamcity-build.log.
You can download it by clicking "Download full build log" on build log page.
I couldn't quite tell if this is what you were talking about when you refer to ##teamcity... lines in your question, but this is what I'm currently doing for command-line build steps (which is currently all I do):
##teamcity[testStarted name='dummyTestName' captureStandardOutput='true']
echo "Do your command-line build steps here."
##teamcity[testFinished name='dummyTestName']
It's sort of a hacky workaround, but it will result in stdout/stderr being displayed on the build log page in the TeamCity web UI.
I see that this question was asked long time ago (almost 10 years ago) but nothing changed in TeamCity.
I faced similar issue with test reporter and found a way to get raw log without connecting to build agent and getting it from there (it may be difficult). My solution does not cover the whole build log, but can be helpful when step is run via custom script in Build Steps.
So the solution is to add | tee e2e_raw.log into required build step script. For example we run tests in Docker by running docker-compose command:
tee will duplicate all the output into the file. Original output will be the same and will be parsed by TeamCity as usual.
You should also add a line into artifacts field to make build able to collect newly created artifact (Build General settings):
After that you will see a new archive in artifacts tab with raw log for this build step:
Great answers here before me. I would add that your TeamCity master holds log files for the builds, and you can get them on the command line.
Have a look in <TeamCity Data Directory>/system/artifacts/<project ID>/<build configuration name>/<internal_build_id>/.teamcity/logs.
This mattered to me because
The logs on the TeamCity agents were getting removed after a day or so, but the logs on the master were still available.
I wanted to grep them on the machine itself without having to download multiple, sizeable log files or use my web browser to make multiple page views.
There's an option on the build log to see 'detailed / verbose' - it shows all the service messages. I've seen it since TC9.
I have an eclipse synchronized project where I do the work on my Windows machine and then synchronize and compile it on the linux build server. However, the Windows workspace is connected to perforce and the linux one is not. The problem is that when Eclipse synchronizes the two, the permissions get messed up on the linux side so that I cannot execute certain shell scripts that usually execute during the build. The workaround that I have would be to somehow chmod all the *.sh files before executing a build, but I would much rather have perforce know about both places (that way I could also commit from either the linux side or the windows side). For performance reasons, I couldn't run eclipse on the remote build server so this was the only solution I found. Also, when I tried setting up a second workspace for the linux side, it gave me errors saying "could not clobber X". I think the main problem is that I'm dealing with some sort of permissions issue here.
I may have found the answer. According to the perforce documentation:
By default, you can only use a workspace on the machine that is specified by the Host: field. If you want to use the same client workspace on multiple machines with different platforms, delete the Host: entry and set the AltRoots: field in the client specification. You can specify a maximum of two alternate client workspace roots. The locations must be visible from all machines that will be using them, for example through NFS or Samba mounts.
Perforce compares the current working directory against the main Root: first, and then against the two AltRoots: if specified. The first root to match the current working directory is used. If no roots match, the main root is used.
Note
If you are using a Windows directory in any of your client roots, specify the Windows directory as your main client Root: and specify your other workspace root directories in the AltRoots: field.
In the following example, if user bruno's current working directory is located under /usr/bruno, Perforce uses the UNIX path as his client workspace root, rather than c:\bruno_ws. This approach allows bruno to use the same client workspace specification for both UNIX and Windows development.
Client: bruno_ws
Owner: bruno
Description:
Created by bruno.
Root: c:\bruno_ws
AltRoots:
/usr/bruno/
To find out which workspace root is in effect, issue the p4 info command and check the Client root: field.
If you edit text files in the same workspace from different platforms, ensure that the editors and settings you use preserve the line endings. For details about line-endings in cross-platform settings, refer to the Perforce System Administrator's Guide.
You could have two workspaces, one for each machine. When you've done the work on the Windows machine, you could shelve the changes, and then unshelve them on the Linux machine and do the build there.
I did the following to set up alternate roots in Perforce:
Created a workspace in Windows
Set the current client (workspace) with "p4 set P4CLIENT=workspace_name", I used Windows+Cygwin to do this
Removed the "Host" from this client (workspace) "p4 client -o | grep -v Host: | p4 client -i" I used Windows+Cygwin to do this
In Linux added the alternate root in P4V, don't use ~, use the absolute path, I didn't test environment variables
Switched to the workspace in P4V
Got the latest revision in P4V, and checked the "Force" option
References:
http://answers.perforce.com/articles/KB/3412
Override host to null in perforce client creation
https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html
sqenixs's answer here