Is there a way to see TeamCity configurations that override parameter defined in template?
I don't think so. What's worked for me in the past was to search through the project files on the filesystem. If you have many build configs, this will be faster than opening each of them in the GUI.
Search for something like this:
<param name="myParamInheritedFromTemplate" value="myOverrideValue" />
in <TeamCity data directory>/config/projects/**/*.xml. If it's absent in an XML file, that build config just inherits the value. If it's present, it overrides it.
It's hacky but it's quick.
There is a feature request https://youtrack.jetbrains.com/issue/TW-21212, please vote. Current workaround are to either search the raw XML files with the settings stored under TeamCity Data Directory on the server as #sferencik suggested, or use REST API to get settings of all the build configurations and search for the parameter there. Let me know if you need help on any of these.
Related
I am using gradle 6.8 and MarkLogic version is 10.0-5.2,
My XQuery code is in directory \ml-gradle\src\main\common. When I run the command mlLoadModules to load XQuery into the modules database it loads with default URI /common/test.xqy.
I want to add some prefix to the URIs e.g. /rsc/common/test.xqy. How can I achieve that?
Note: I don't want to create an extra folder in my source for prefix "rsc".
It's not supported, though you could write a custom Gradle task to change the URI to whatever you like.
Why do you not want to create an "rsc" folder above "common"? I think other developers would find it much more intuitive that "rsc/common/test.xqy" becomes "/rsc/common/test.xqy" when loaded, rather than "common/test.xqy" becomes "rsc/common/test.xqy", which begs the question - where is "rsc" coming from? And then that developer would need to understand what property / custom code is adding that "rsc".
I'm working on some .Net framework application and i've been asked to send the logs to elasticsearch using kibana as the UI.
To have something that is standardized i have to implement ECS (Elastic Common Schema).
Looking at the example we have on ECS github we only have to implement it on the following way:
Instead of sending to console, like we have on the example i send it to elastic search
The output from it, would be a nice Json object...
Maybe it is expected that on kibana we would see something like the following (Kibana - Discover):
Looking at that, probably the Json Object is supposed to be treated as a string and everything goes inside the message property, but that is not what i'm looking for, i want that json to be divided in many properties.
Since i'm new to Elastic stack world, i've tried to create a template inside the Index Management page and the performing there manual mappings like message._metadata.url to not treat some properties as part of the string but without success.
I'm having trouble finding useful information to solve this problem, can anyone give an hint?
UPDATE:
I found the property enableJsonLayout="true"that we can put on the target of Nlog that indeed turns whats on the Json layout as properties on ElasticSearch which is good.
Is this the right way to use ECS?
How can i add aditional properties?
When you enable this enableJsonLayout="true" then it means that the configured Layout has to handle everything. For EcsLayout then you can find the documentation here:
https://github.com/elastic/ecs-dotnet/tree/master/src/Elastic.CommonSchema.NLog
EcsLayout will by default include all LogEvent Properties as metadata. See also https://github.com/NLog/NLog/wiki/How-to-use-structured-logging
But you can explicit add extra metadata-items:
<layout xsi:type="EcsLayout">
<metadata name="MyProperty" layout="MyPropertyValue" />
</layout>
I was looking for a configuration parser for go and https://github.com/spf13/viper seems to come highly recommended.
I am very surprised to find that configuration files are not validated by default.
Viper parses files and extracts requested values from them but I cannot find a way to detect bad configuration.
For instance I if create a (Java style) .properties file containing just "???" and nothing else. This is accepted without any error.
I can understand the philosophy that you should ignore irrelevant configuration items but I desire more rigor. I would also like to reject anything that does not match the X=Y format in a properties file.
To me this is a fatal flaw that suggests I should use a different package (or roll my own as usual).
Have I missed something? Does viper in fact support detecting and rejecting bad configuration keys?
I think the answer is no. viper does not validate java .properties files.
I posted a bug report (or feature request depending on your point of view) as https://github.com/spf13/viper/issues/790
You can try https://github.com/num30/config library which is based on Viper. It has built-in validation.
my Firefox addon shall add a search engine, that
provides suggestions
gets its search template URL specified on runtime (i.e.: template URL depends on the preferences of the user)
And I don't see a way to do both at the same time.
I see two options to add a search engine:
addEngineWithDetails
addEngine
addEngineWithDetails() allows me to add a search engine with the template URL. But it does (apparently?) not allow to provide a suggestions URL.
addEngine() allows me to add a search engine that is specified in an XML file. But if have that file saved locally in my addon directory (e.g. chrome://example-engine/content/search.xml), how can I change the template URL on runtime? And using an online XML is an unsafe options since the internet connection could be broken or bad during the addon install.
First fo all, you're right, addEngineWithDetails does not support suggestions.
The way to go would be to use addEngine (and removeEngine).
As for the "dynamic" part of your question: While I didn't test it, the implementation seems to happily accept data: URIs. So you could:
Construct a data URI using whatever methods you like (even constructing a full XML DOM and serializing it).
Call addEngine with the data URI.
When the user changes a pref, remove the old engine, and construct a new one.
I am developing an application in ServiceStack and am trying to sort out deployment on AppHarbor, however for some reason my web.config transforms are not being applied.
I had originally a Web.AppHarbor.config file and changed the Environment Setting to "AppHarbor" - once this failed to work after several updates, I gave up and changed the Environment setting to "Release" and copied the desired transformations into the Web.Release.Config file.
App gets deployed OK but config settings do not reflect the values in the transform file (I verify this by login on with twitter and seeing the callback url for Twitter Auth still tries to redirect me to localhost, which is one of the settings I change in my transform file)
I have also tried the transform tester tool and all works as expected.
Manually publishing the web application to a local folder correctly applies the transformations according to the selected configuration
Does anyone have this working? Is there something obvious I'm missing?
Thanks
It sounds like the Web.Release.config file is not included in the build output. You need to set the Build Action attribute to Content to include it in the build output.
You can confirm whether the file is included in the output by downloading the build from the log page.
I stumbled across this post because I was seeing the same lack of action myself. Upon closer inspection (about 15 times that is) of my Web.Release.config I realized one of the nodes in my config file was not marked xdt:Transform="Replace". Unsurprisingly it did nothing when deployed.