Brand new to teamcity (~2hours), and I ran into a problem. How does one generate or create a "Build Configuration ID"? After searching google and stack, there doesn't seem to be much more than documentation of what it is. Is this something very simple, or can I just make up my own?
When you create a build configuration, it will pretty much get automatically generated from the Parent(s) and Config Name
You can edit this field if you want.
Related
I am new to FHIR and HL7.
I need to add a new element to ChargeItemDefinition resource and this element data type is CodeableConcept.
I think we need to create a new StructureDefinition with a CodeableConcept field and then register it on the server and make an extension in ChargeItemDefinition.
I tried a tool like Forge to make a custom profile, but creating a new profile or extension is disabled.
But I can't make it after days of trying, does anyone have an example of this or is anyone able to help me?
Forge should perfectly allow you to create a profile based on ChargeItem, if you want to add extensions to that profile. With Forge for FHIR STU3 or R4 (depending on what version you want to use): Open a project folder > New > New Profile > Select Charge Item.
However, without knowing your use case it is hard to judge whether this is what you need. If you share a good description of the use case on chat.fhir.org in the 'implementers' channel people can generally quickly advise you on the best way.
Is there a way to set project tags similar to project key (sonar.projectKey) in the sonar-qube.properties for tags to be automatically added during project creation?
I was looking through the docs:
https://docs.sonarqube.org/display/SONAR/Analysis+Parameters
https://docs.sonarqube.org/display/SONAR/Project+Settings
and wasn't able to find info
Thanks
It can be done via the API.
curl https://my-sonar-server.com/api/project_tags/set?project=projectName&tags=foo,bar,baz,mumble
It is there a bit hidden under Project Information, Description it is possible to add the tags there... I was a bit lost for this myself... SQ is not great in terms of UI. You can type your tags and they will be possible to filter them.
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.
I'm new to Thymeleaf / Spring and have just introduced a message_en.properties file. I see the benefits of using it, however, it's a bit of a pain to populate it.
I have a form, I've just added several inputs, I know need to add each of these as keys in the message file. Is there a way of doing this on the fly for me?
To automatically populate the message properties, you may have to consider using a scaffolding solution like jHipster or something similar.
refer http://jhipster.github.io
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.