Running 2020.1.1 (build 78657)
I have a VCS root for a Perforce Stream Depot (with the option to Enable feature branches support).
I also have several builds with Version Control Settings having VCS checkoutmode set to Prefer to checkout files on agent.
However, I am seeing these messages in the build logs:
[Updating sources] Will use server side checkout: Checkout rules are not supported for vcs root 'StreamRoot'. Details: Perforce stream checkout on agent supports only one single include rule like . => sub/directory, requested rule: +:area/functions/functionsA => .
This message is confusing to me, because I only have a single checkout rule (as shown in the log):
+:area/functions/functionsA => .
I would appreciate any insight from the community.
I think the issue here is the message isn't so descriptive. I've also come across this problem, and seems it only works when specifying a single rule that applies to the whole stream, e.g. +:. => some/path
Related
I am using TeamCity Enterprise 2021.2 (build 99542) and Bitbucket Server v7.14.0. I have a build configuration in Teamcity with 3 VCS roots: Repo1, Repo2, and Repo3. Each repo has a "main" branch, which is the default branch for all 3 repos. Repo 1 and 2 have a branch called "feature1".
If I set the branch specification in all 3 repos to refs/heads/* and set up a VCS trigger to Repo1 with the filter as +:* the desired behavior is achieved. A build is triggered when a change is made to feature1 in Repo1, and the build checks out feature1 on both Repo1 and Repo2, while main is checked out on repo3.
The problem is that I only want to trigger a build when a pull request is created or updated in Repo1. So, I use the Pull Request build feature to trigger with any pull request in Repo1, and set the branch specification in Repo1 to refs/heads/main (so duplicate builds aren't triggered) This results in almost the desired behavior.
I create a PR for feature 1 in Repo1 in bitbucket. And a build is triggered. The problem is that feature1 is only checked out in Repo1 but NOT Repo2. Is there any way to configure a VCS root for Repo2 to check out the same branch that is being used on Repo1 while builds are being triggered by PRs to Repo1?
I suspect the problem is related to some of the TeamCity build configuration variables. In the first case with the expected behavior, teamcity.build.branch is set to refs/heads/feature1. yay. In the second case, teamcity.build.branch is set to pull-requests/## while teamcity.pullRequest.source.branch is set to feature1.
It is not even a problem of variables, but a problem of the build (logical) branch.
If you are using the Pull Requests build feature it (internally) expands the branch spec of the VCS root in the context of your build configuration with patterns that include refs/pull-requests/123/from kind of branches provided by Bitbucket Server for pull requests.
So the logical branch name for the build becomes pull-requests/123, not a source branch of the pull request. As other repos do not have such pull requests in them, for them default VCS branches are selected. Which is in most cases ok, as such things as multi-repo pull requests are not supported by any VCS hosting. Not in my knowledge at least. In our opinion in most cases the following improvement could be useful for many users: to fall back to a VCS branches that match the target branch of the pull request instead of the default branch of the VCS root. This is to be discussed if such feature requests appear.
Anyway your case is different and it seems you want to use source branches in all three repos. If the following feature request is fulfilled it may satisfy your needs: https://youtrack.jetbrains.com/issue/TW-70491
We are currently working on it and it may appear as an experimental feature in one of our bugfix releases soon and as a proper feature in the next feature release this year. Please follow that issue to keep updated.
Cheers,
Anton
Does the TeamCity build feature Pull request automatically build a pull request against master? I'm not talking about merging automatically into master just building against it.
I can't seem to find any documentation. Previously in TC I could see two kinds of branches 33/merge and pull/33, with the build feature enabled I can only see pull/xx being triggered. In the build summary it does state Submitted into refs/heads/master, from xxxx-pull-request by xxxxxx
So I can only assume it is running the pull request against master based on the text above, however I can't seem to find any documentation to indicate this.
It is not automatic, it depends how vcs root is set
To build PR revision merge with current master set VCS root +:refs/pull/(*/merge)
See https://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/
I have 2 separate Teamcity web application instances running on separate servers accessing the same git repository.
This seems to be causing issues with the VCS root configuration.
The specific error message is:
Error collecting changes for VCS repository ... 'git fetch' command failed... 301 Moved permanently
I get this message for every build configuration with every teamcity project in my installation.
I must maintain 2 separate teamcity application instances on different servers - one that builds Microsoft Windows software artifacts and the other that build Linux based artifacts.
The only workaround that I currently have for this problem is to delete the VCS root and set it up again - only to discover that the next day the problem is back.
I can't keep doing this forever - there must be a better way to address this.
Does anyone know how?
After working with Jetbrains support, they root caused the issue to the use of http:// in the github URL instead of https://.
So, IOW, when you specify a github repository URL, you must use https:// in a temmcity VCS root configuration.
I have a Gerrit project without any dashboards defined. To make the differentiation between multiple projects on the same Gerrit server easier I would like to create a new dashboards for one of the projects.
The official documentation (at least as of v2.13.5-2456) assumes that the necessary branch where the dashboards are to be created already exist, which ist not the case on my installation. As such, the necessary steps for the first dashboard for a project are omitted there.
So the question is: What are the necessary steps to create a first dashboard for a project? Are there any pitfalls? If so, how can they be avoided?
The biggest problem is creating the new meta branch where the dashboards will be housed. For that you need to make sure the user has the following access rights for the reference refs/meta/dashboards/*:
CreateReference
Push
Now check out your project as usual with git clone ssh://<user>#<server>:29418/<path/to/project> (you may want to adjust the port as necessary). You will have the current master branch in your working directory. However, the dashboards branch only works if the only files in it are actual dashboard configurations.
To solve this you have to create a new orphan branch, which does not have any history or files in it. That can be achieved with git checkout --orphan dashboard_local.
On this branch you can create your dashboard configuration with the syntax as documented in the official manual. Commit this file and make sure that no files other than dashboard configurations are in this branch.
Now this branch needs to be pushed to the server. You can use the regular Gerrit syntax here: git push origin HEAD:refs/meta/dashboards/<group>. Using the <group> identifier you can group several dashboards together in the Gerrit Web-UI.
If you made no syntax errors your dashboard should now show up and new dashboards can be added to this existing branch.
Based on:
An explanation of emtpy (orphaned) branches in git
MediaWiki Help on Gerrit dashboard
We have a Subversion repository setup in this manor:
http://svn.vegicorp.net/svn/toast/api/trunk
http://svn.vegicorp.net/svn/toast/api/1.0
http://svn.vegicorp.net/svn/toast/data/trunk
http://svn.vegicorp.net/svn/toast/data/branches/1.2
http://svn.vegicorp.net/svn/toast/data/branches/1.3
I've setup a Jenkins Multi-Pipeline build for the entire toast project including all sub-projects -- each sub-project is a jarfile. What I want is for Jenkins to fire off a new build each time any file is changed in one of the toast projects. That project should rebuild. This way, if we create a new sub-project in toast or a new branch in one of the toast sub-projects, Jenkins will automatically create a new build for that.
Here's my Jenkins Multi-Branch setup:
Branch Sources
Subversion
Project Repository Base: http://svn.vegicorp.net/svn/toast
Credentials: builder/*****
Include Branches: */trunk, */branches/*
Exclude Branches: */private
Property Strategy: All branches get the same properties
Build Configuration
Mode: By Jenkinsfile
Build Triggers (None selected)
Trigger builds remotely (e.g., from scripts) Help for feature: Trigger * builds remotely (e.g., from scripts)
Build periodically Help for feature: Build periodically
Build when another project is promoted
Maven Dependency Update Trigger Help for feature: Maven Dependency Update Trigger
Periodically if not otherwise run
Note that the list of Build Triggers list does not include Poll SCM. Changes in the repository does not trigger any build. Jenkinsfiles are located at the root of each sub-project. If I force a reindex, all changed sub-projects get built and all new branches are found. I did originally checked Periodically and reindexed every minute to pick up a change, but that's klutzy and it seems to cause Jenkins to consume memory.
Triggering a build on an SCM change should be pretty basic, but I don't see a configuration parameter for this like I do with standard jobs. I also can't seem to go into sub-projects and set those to trigger builds either.
There must be something really, really simple that I am missing.
Configuration:
Jenkins 2.19
Pipeline 2.3
Pipeline API: 2.3
Pipeline Groovy: 2.17
Pipeline Job: 2.6
Pipeline REST API Plugin: 2.0
Pipeline Shared Groovy Libraries: 2.3
Pipeline: Stage View Plugin: 1.7
Pipeline: Supporting APIs 2.2
SCM API Plugin: 1.2
I finally found the answer. I found a entry in the Jenkins' Jira Database that mentioned this exact issue. The issue is called SCM polling is not being performed in multibranch pipeline with Mercurial SCM. Other users chimed in too.
The answer was that Jenkins Multi-branch projects don't need to poll the SCM because indexing the branches does that for you:
Branch projects (the children) do not poll in isolation. Rather, the multibranch project (the parent folder) subsumes that function as part of branch indexing. If there are new heads on existing branches, new branch project builds will be triggered. You need merely check the box Periodically if not otherwise run in the folder configuration.
So, I need to setup reindexing of the branches. I'm not happy with this solution because it seems rather clumsy. I can add post-commit and post-push hooks in SVN and Git to trigger builds when a change takes place, and then reindex on a periodic basis (say once per hour). The problem means configuring these hooks and then keeping them up to date. Each project needs its own POST action which means updating the repository server every time a project changes. With polling, I didn't have to worry about hook maintenance.
You never mentioned setting up a webhook for your repository, so this may be the problem (or part of it).
Jenkins by itself can't just know when changes to a repository have been made. The repository needs to be configured to broadcast when changes are made. A webhook defines a URL that the repository can POST various bits of information to. Point it to a URL that Jenkins can read, and that allows Jenkins to respond to specific types of information it receives.
For example, if you were using github, you could have Jenkins listen on a url such as https://my-jenkins.com/github-webhook/. Github could be configured to send a POST as soon as a PR is opened, or a merge is performed. This POST not only symbolizes that the action was performed, but will also contain information about the action, such as a SHA, branch name, user performing the action... etc.
Both Jenkins and SVN should be capable of defining the URL they each respectively POST and listen on.
My knowledge lies more specifically with git. But this may be a good place to start for SVN webhooks: http://help.projectlocker.com/knowledge_base/topics/how-do-i-use-subversion-webhooks
Maybe you need something under version control in the base directory. Try putting a test file here http://svn.vegicorp.net/svn/toast/test.txt. That may make the poll SCM option show up.