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.
Related
For one of our repositories we set "Custom CI configuration path" inside GitLab to a remote gitlab-ci.yml. We want to do this to prevent Developers to change the gitlab-ci.yml file (as protected files are available in EE Premium and up). But except this purpose, the Custom CI configuration path feature should work anyway for Merge Requests.
Being in repo
group1/repo1
we set
.gitlab-ci.yml#group1/repo1-ci
repo1-ci repository exists and ci works correctly when we push to configured branches etc.
For Merge Request functionality GitLab tells us:
Detached merge request pipeline #123 failed for ...
Project group1/repo1-ci not found or access denied!
We added the developers to repo1-ci repo as developers, to be able to read the files. It does not help. Anyway the expectation is, that it is not run with user permissions, so it should simply find the gitlab-ci.yml file.
Any ideas on this?
So our expectations were right an it seems that we have to add one important thing into our considerations:
If a user interacts in the GitLab UI with the Merge Request features and you are using "Custom CI configuration path" for your gitlab-ci.yml file, please ensure
this user needs at least read permissions to that remote file, even if you moved it to another repo on purpose (e.g. use enhanced file protection in PREMIUM/ULTIMATE or push/merge protect the branches for the Developer role)
the user got this permission change applied in a running session
The last part failed for our users, as it worked one day later. Seems that they just continued working from their open merge request page and GitLab checks the accessibility out of this session (using a cookie, token or something which was not updated with the the access to the remote repo/file)
It works!
I'm the only developer in a team and will be working on a private project that doesn't need to be placed on the Github or somewhere else online. My entire project will be located in one of my local machine folders. Is this possible to create a project in TeamCity that points to my local folder? I'm using TC version 10. When I navigate to Create Project i only see Manually, Github, URL Repository and BitBucket Cloud Repository. Logically thinking I went to set up the project Manually, but there is a field Project ID which seems like require some sort of URL. Just curious if this ever possible with Team City? Thanks.
Yes, it is possible.
Choose git as a type of repository and in mandatory field Fetch URL specify local path: /path/to/repository.
Click Test connection to make sure Teamcity is able to fetch data.
You won't be able to configure triggers against this repository, it is still open issue: https://youtrack.jetbrains.com/issue/TW-12162
See screenshot .
with TC 2017.2.2 from URL Repository you can just give the path
file:///home/user/dirOfProject
I'm trying to get the netty-codec-hhtp going in my maven project. I have a completely standard Sonatype Nexus set up to proxy requests to Maven Central.
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http</artifactId>
<version>4.0.9.Final</version>
</dependency>
This fails when building using maven. If I search for it manually in Nexus I find it, but if I go to download the jar it tells me:
404 - Not Found
Automatic routing filter rejected remote request for path /io/netty/netty-codec-http/4.0.9.Final/netty-codec-http-4.0.9.Final.jar from M2Repository(id=central)
What does this even mean, why am I getting it, and maybe more importantly, how do I fix it?
I am using Nexus 2.5.0-04 with Maven 3.0.4
Downloading other artifacts seems to work just fine.
UPDATE: This turned out to be an issue with CDN configuration that should now be resolved. The steps below for forcing and/or disabling remote discovery are left for reference.
It means that Automatic Routing for Central is active, and that the discovered rules does not contain io.jetty as allowed prefix.
This should not happen, as the default configuration should update the rules on daily basis (as seen on screenshot below, showing the default Automatic Routing configuration for Central).
The remedy is to either force the update of rules (I did check, prefix /io is among rules Central publishes), or disable remote discovery completely.
Try steps as shown below on screenshot:
From Repository Management with Nexus - 6.4. Managing Routing:
Routing can be considered the internal activities Nexus perform in order to determine, where to look for a specific component in a Maven repository. The routing information has an impact on the performance of component retrieval as well as determining the availability of components.
(...) Automatic Routing is handled by Nexus on a per repository basis.(...)The Routing information consists of the top two levels of the directory structure of the repository and is stored in a prefixes.txt file. It allows Nexus to automatically route only component requests with the corresponding groupId values to a repository to avoid unnecessary index or even remote repository access.
Since Maven central repo contains that artifact I assume that the automatic routing rules forbids remote download for that artifact. The error message you posted suggests it also.
You can read how to add a routing rule under 6.4.2. Manual Routing Configuration. If my assumption is correct, this situation shoud be resolved by adding an inclusive rule type with ^/io/netty/.* route for central repo.
I faced the same issue when configuring a bridge between 2 Nexus.
In the first:
I added 2 proxy repo, targeting 2 public repo groups in the second,
then aggregate those 2 proxy repos in a new group,
that I finally added to the repo list of the first Nexus public repo group
Using the first Nexus, each time I requested a dependency only present in the 2nd, I encountered the Automatic routing filter rejected remote request for path... exception.
As mentionned by Tamas, this issue comes from the Routing >> Discovery feature that was enabled in my 2 proxy repos, that were targeting remote Nexus repository groups.
Once disabled, the issue was solved.
The exact explanation of this need is in some way explained in the official Sonatype documentation for Repository Management with Nexus, in chapter 6.4.1 on Automatic Routing:
The Routing tab for a proxy repository displayed in Figure 6.18,
“Automatic Routing for a Proxy Repository” contains the Discovery
section. It displays the Status and a more detailed Message about the
prefix file access. The Last run field displays the date and time of
the last execution of the prefix file discovery. Such an execution can
be triggered by pressing the Update now button. Otherwise, the Update
Interval allows you to trigger a new discovery every one, two, three,
six, nine or twelve hours or as a daily or weekly execution.
[...]
For a proxy repository, the prefix file is either downloaded from the
remote repository or a generation is attempted by scraping the remote
repository. This generation is not attempted for remote Nexus
repository groups, since they are too dynamic in nature and should not
be proxied directly. Scraping of hosted or proxy repositories as well
as Subversion-based repositories is supported.
Regards,
Thomas
Rather than having teamcity log onto the gitolite server several tens of thousands of times each day - and also sitting around waiting for the poll to happen (or starting it manually).
It would be nice if it was possible to set it up gitolite hooks that inform TeamCity that the repository has changed.
Is such a configuration possible with TeamCity and gitolite?
I know Jenkins has a github plugin that works nicely - I use that setup for some Minecraft CI I am running privately.
One way would be to gitolite (through a VREF hook) to call TeamCity through its REST API, in order to launch a build through web request.
You just need to make web request to the following URL:
http://YOURSERVER/httpAuth/action.html?add2Queue=btId
, where btId is build type Id – unique identifier for each build configuration.
To get it, you can just look for it in browser address bar, when clicking on build configuration, or use TeamCity REST API for details.
The OP Morten Nilsen didn't need a VREF:
add a file "post-receive" to .gitolite/hooks/common and
run gitolite setup --hooks-only
I have a strange SVN server configuration issue I cannot figure out.
A previous employee setup Collabnet svn server (version 1.6.9) on a windows server at work which we use for development. It's a great system, love using it.
We use a local LAN path for the repository with all our various folders, like this...
"svn://server1"
It has one repository called "repo".
I have recently installed a second SVN on another server (same version, same OS)
It has one repository called "main". In order to access it I have to use the svn path of ...
"svn://server2/main"
So the question is.... does anyone know how we ended up with one server requiring to use a "repo name" after the server name (and does not work without it) and one server not requiring a "repo name" (and does not work with it)?
The main reason for asking is I also need to setup additional repositories on the original server and do not want to affect the current configuration. I assume this is some level or option or configuration or a "default repo" setting or something, but I just can't seem to find where and how it was set.
Check the entry in your conf file. If you have your svn information within a location tag, the location is the only way to access the repository.