I have an app with a module that contains two schemes, SchemeA and SchemeB.
When running SchemeA, it uses a target called FirstTargetA.
When running SchemeB, it uses a target called FirstTargetB.
I also have another module in my app which contains two targets: SecondTargetA and SecondTargetB. The only diff between those two are different custom flags.
I have added SecondTargetA as a framework to FirstTargetA and added SecondTargetB to FirstTargetA, but when I run SchemeB, FirstTargetB is actually calling SecondTargetB and I don't understand why. It should even know it as it's not in the General->Frameworks, Libraries and embedded content section.
Can anyone tell me what should I look for? What could I miss?
I am a new NativeScript user and I am trying to understand how to have my app make a GET call to a remote server, depending upon environment. In Java world we pass in an environment variable, but I have not found an example (that I understand) demonstrating how my NativeScript mobile app will know which environment it is running in, and how to get values based upon that.
I am presuming that I will have a config/ with files such as
prod.conf.js and dev.conf.js - and there is where I will put in my urls and other config values.
How do I get my NativeScript (which I will eventually build into iOS) to reach those values to use in an http request upon startup. Any example to direction to documentation would be greatly appreciated.
Answer:
I finally got the problem solved by using Manoj suggestion of nativescript-dev-appconfig. For any newbie looking for help, try this:
{PROJECT_ROOT}/config - create the environment files as {env}.json. These files are just json, with name-value pairs of the values you want. In may case that is
When you do your build: tns build ios --bundle --env.config {dev | test | prod }
This will take the contents of the selected env.config file (ie -env.config dev and copy it as - {PROJECT_ROOT}/app/config.json .
To use it within your code,
import config from "../config.json";
axios.get(config.MY_URL).then(result => {...}
Unfortunately using environment based config files are not officially supported but there is a plugin hook you could try.
We also have webpack based environment variable support, read more about that in the docs.
I want to package a Grails application for different brands. While generating a war file, I want to pass some custom parameter that refers to a certain brand and styles the application by loading the stylesheet for the brand.
I read online and one approach I found was with maven. I tried working with maven but I am stuck while initially compiling the application. The error is
Failed to execute goal org.grails:grails-maven-plugin:2.2.1:maven-compile
(default-maven-compile) on project foreAction: Forked Grails VM exited with error.
I am stuck as to what approach to take now. I searched for the above error and tried different solutions but nothing seems to work.
If there is a different way without using Maven I am willing to give it a shot.
You could always hook into the events using scripts/_Events.groovy and replace the appropraite CSS/assets. The documentation explains how to hook into build events.
Your code inside scripts/_Events.groovy might look something like this:
// This is called after the staging dir is prepared but before the war is packaged.
eventCreateWarStart = { name, stagingDir ->
// place your code here that copies your resources to the appropriate location in the staging directory.
Ant.copy(
file: System.getProperty('somePassedInFile'),
toFile: "${stagingDir}/assets/stylesheets/whatever.css",
overwrite: true
)
}
Then you can pass in the value of the source file from grails prod war like this:
grails prod war -DsomePassedInFile=/path/to/file.css
Hope this helps at least give you an idea of how you can accomplish this. (All written off the top of my head so beware of typos etc.)
Is there any package like CodeSleeve/asset-pipeline for laravel 4 where you have:
-concatenation
-minification
-add resources at runtime from Views/Controllers
-adding on a file by file basis
Asset-pipeline is great for the most part, but the only way to add specific files is using a manifest.
You can listen for the asset.pipeline.boot event and add whole folders for the pipeline to auto load but this is not what i need.
Event::listen('asset.pipeline.boot', function($pipeline) {
$config = $pipeline->getConfig();
$config['paths'][] = 'some/special/javascripts'; // this must be a folder
$config['paths'][] = 'some/special/stylesheets'; // this must be a folder
I've also seen a previous topic very similar to this one Laravel replacement for Asset::add but they don't have concatenation of resources, are no longer maintained or have external dependencies like node/ruby and can't be used on runtime anyway.
I'm looking for a way to attach some specific build parameter to a scheduled trigger.
The idea is that we are continuously building debug versions of our products. Our nightly build has to be a release build, though. The build configurations for most of our projects is absolutely the same. It even has a configuration parameter, already. So all I would need is a trigger which allows for specifying an override for a single build parameter. That would cut the build configurations to maintain by half.
Is there a way to achieve this?
Not right now, you can follow this issue.
The approach I use is to create a "Deploy :: Dev D1 :: Run all integration tests" build. I then create a build trigger on each integration service build.
I create a parameter called "env:OctopusEnvironment" for integration service build. Set the value to be empty. I like to use prompt and display:
select display='prompt' label='OctopusEnvironment' data_13='Production' data_12='CI' data_11='Local - Hassan' data_10='Local - Mustafa' description='OctopusEnvironment' data_02='Test T1' data_01='Dev D1' data_04='Local - Taliesin' data_03='Continuous Deployment CI 1' data_06='Local - Paulius' data_05='Local - Ravi' data_08='Local - Venkata' data_07='Local - Marko' data_09='Local - Ivan'
In each integration service build I add this powershell step:
$octopusEnvironment = ($env:OctopusEnvironment).Trim()
Write-Host "Octopus environment = '$octopusEnvironment'"
if ($octopusEnvironment.Length -lt 1) {
Write-Host "Auto detecting octopus environment"
$trigger = '%teamcity.build.triggeredBy%' -split '::'
if ($trigger.Length -gt 2){
$environment = $trigger[1].Trim()
Write-Host "##teamcity[setParameter name='env.OctopusEnvironment' value='$environment']"
}
}
So now I can run the integration test via a trigger and when I run it directly it will prompt me on which environment to run integration test against.
I was stuck with the same problem and voted for the issue mentioned by Evgeny. One solution we thought, as mentioned sergiussergius, was to add a final step in the build-steps sequence to trigger manually the next build-configuration by passing custom-build parameters using the REST API. But in this case, we are loosing the build-chain information.
Using TeamCity 9.x, trying some stuff on the REST API, I could implement a solution who makes it possible to retrieve the triggering (ancestor) build and its parameters from the triggered (child) build.
The first thing we do is getting the current build using the environment variables set by TeamCity:
https://<host>/httpAuth/app/rest/builds/number:<env.BUILD_NUMBER>,buildType:(name:<env.TEAMCITY_BUILDCONF_NAME>,project:<env.TEAMCITY_PROJECT_NAME>)
In the response from the REST API, we have a /build/triggered tag which contains information about the trigger. It looks like this
<triggered type="unknown" details="##triggeredByBuildType='<triggering-build-configuration-internalId>' triggeredByBuild='<triggering-build-number>'" date="20160105T190642+0700"/>
The looks like btxxx for us.
From it, we can access the triggering-build (ancestor) using the following request to the REST API:
https://<host>/httpAuth/app/rest/builds/number:<triggering-build-number>'4,buildType:(internalId:<triggering-build-configuration-internalId>1,project:name:<env.TEAMCITY_PROJECT_NAME>)
from the response, we can get the ancestor-build's parameters values, and set it in the current build using:
echo "##teamcity[setParameter name='env.ENV_AAA' value='aaaaaaaaaa']")
Notes:
this post reference TeamCity version 7.X. I did this using TeamCity version 9.X, and could not try it with a previous version. I don't know if the REST API calls mentioned in my post are similar in the previous versions.
In this solution, the ancestor's build-configuration (the one who trigger the build) and the child's build-configuration (the one triggered) are in the same project. I did not do the test using build-configurations in 2 different projects: I would expect the "trigger" tag to provide information about the ancestor's project. It would be nice if someone could do the test.
I hope this solution may help!
This is not a general solution, but in certain cases (for example if you want to determine whether the build was started by a schedule trigger or some other method), a workaround is to examine the predefined parameter teamcity.build.triggeredBy.
This parameter is set to the same string that is shown on the build's overview page next to the label "Triggered by:". For example, "Schedule Trigger", "Git", or a user's full name. (There is also a teamcity.build.triggeredBy.username parameter, but it is only set in the latter case).
The limitation of this approach is that you cannot, for example, distinguish between two separate schedule triggers defined for the same build configuration. But in that case you could resort to examining the current time as well.
I added request to last build step
curl -i -u "%login%:%pass%" -H "Content-type: text/plain" -X PUT -d "v1" http://tc.server/httpAuth/app/rest/buildTypes/id:%buildConfigurationId%/parameters/env.%SOME_PARAMETER%
http://confluence.jetbrains.com/display/TCD8/REST+API