Get CircleCI environment variables into Swift via Fastlane - swift

I want to add some secrets to CircleCI environment variables so that its not hardcoded in my project for security and so that we can cycle them as needed too.
I know I can access the environment variables from Fastlane with ENV["SOME_ENVIRONMENT_VARIABLE_KEY"] and from what I understand I can pass that into build_app's xcargs parameter. This is supposedly then available in build phase in Xcode.
eg build_app(..., xcargs: "Testing='SUCCESS'")
I cannot seem to find much documentation on this but I did see in a couple questions that you should be able to add a step to Build Phases and then in the script you export an environment variable that can be used in code. I tried export TESTING=${Testing} and when I try access that in code it (with ProcessInfo.processInfo.environment["TESTING"]) it comes back as nil.
I was not convinced that my script was actually doing anything so hardcoded it in the build phase to export TESTING="SUCCESS" and even then ProcessInfo.processInfo.environment["TESTING"] comes back as nil, just to be sure I added a breakpoint and printed ProcessInfo.processInfo.environment.keys and the TESTING key is not present
I have tried running from Fastlane directly with both the hardcoded value in the build phase and the variable that should come back from Fastlane and, despited me having prints in the unit test and echos in the script, nothing prints (It does print ▸ Running script 'Set up environment variables from CircleCI' but not my debugging echos where I print a string just to see where I am and try print all the environment variables and doesn't print anything for the unit test)
Am I missing something very obvious here? Surely it shouldn't be this complicated?
Thanks in advance

Related

VSCode Test Explorer Pytest Inject Environment Variables using AWS Parameter Store

I am currently Using Pytest though the Python Test Explorer (see screen). I would like to pass my tests some environment variables at runtime. However, I currently get my AWS Parameter Store BEFORE I run tests. Meaning, I run a command in BASH that loads my environment variables into my current terminal session. Then I can run my test from the command line using pytest exampletest.py, and it finds the environment variable perfectly.
Trying to run exampletest.py from the integrated VSCode Test Explorer results in an error telling me that it could not find my environment variable. This means that whatever environment that is used when you hit the "Play Button" on the Test Explorer is not the same terminal session that I set my environment variables in.
The conventional way of setting environment variables such that they can be accessed when using the Test Explorer in VSCode is by either using an ini file or a .env file. The only caveat there is that you must hardcode the key value pair. I would not like to hardcode anything, as I would just like to inject them in at runtime from aws Parameter Store.
I really would like to continue using the Test Explorer to run my tests, as it has been great in the past, but if I cannot find a way to somehow get the Test Explorer to use my environment variables without using an ini or a .env file, I may have to abandon it.
Some questions:
When you click the play button on the Test Explorer to execute a test or suite of tests, what exactly happens? Does it open a Terminal session? Can you access that terminal session before runtime?
How does the Test Explorer set environment variables. When I raise Exception(os.environ), I can see all the environment variables that are quite different from the ones that I get when I run from the command line.
Is there a way to say "Hey Test Explorer, please run the tests inside of this specified Terminal window that is already running"
Perhaps a virtual environment is a way to go (not really a question more of a thought). Doing some cursory research reveals more headaches to come if I pursue this route I believe.
Do you have any further reading about that VsCode Test Explorer that goes beyond the official documentation. I feel like I can make some changes to it's source code or something, but I feel like documentation on it is a bit lacking.
Let me know your thoughts on this matter, and thanks in advance.
I have the same question. The only way I could make it work was by this unwieldy series of steps before running the tests via the vscode UI:
Execute your script or command in a terminal to set the env
variables.
Copy those env variables into your .env file (placed at the root of your project/vscode-workspace). I usually do :
env | grep AWS_ or whatever you want and you'll see them as name-value pairs. I then copy and paste those entries at the bottom of the .env file each time I run the test via the UI.
Now execute your tests via the vscode UI (the test 'beaker'/flask). The testing UI/flask seems to execute the .env file every time before it runs the tests and hence picks up those env variables.
I know, it's not preferable - you would want it to just pick it up from the env values you see in your integrated terminal but so far that is not happening.

PowerShell script builds the wrong path in TFS2017

I am adding a PowerShell script to run in my build to get the Version Number for the build. When I use the builder(Box with ...) to get the file, it takes me to my TFS Project and I work my way down to the file. When the build definition runs it fails at that step, because it cant find my script.
What it has done is prepended the local Servers work directory to the front of the Path it had me choose.
I feel this is a Bug or how am I suppose to get the most current copy of a script in TFS when the Build Definition runs.
Tried with a simple powershell script on my side, but couldn't reproduce your issue, the script is working.
Only add one step in build, and map to $/teamproject in Repositity, then select the script:
To narrow down the issue, you could create a new pipeline with only one task-Powershell, check what will happen.
If you still get error, please share detail logs with system.debug=true enable.
Also take a look at this tutorial about how to use powershell fetch/change build number, which may helps-- Use a PowerShell script to customize your build pipeline
Update
According to your error info, you are lacking of the definition.
Please make sure you have specified the value in options--build number format
$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
Then it should run without any problem:

TeamCity - AssemblyInfoPatcher not using updated variable

I'm changing the build number of the TeamCity (9.1.4) build with service messages (Build Script Interaction) like this in Powershell:
Write-Host "##teamcity[buildNumber '$version.$arg2']"
This is working absolutely fine.
The problem is that the AssemblyInfoPatcher doesn't want to use this updated build number.
So I tried to use a variable/parameter for it but this also doesn't work.
I defined the following variable "Major.Minor.Patch" as a "Configuration Parameter" or as an "Environment Variables". The AssemblyInfoPatcher is using these variables just fine and changes the file version of my files with the version defined in TeamCity in the build.
If I try to change the variable/parameter with a service message it doesn't work. The AssemblyInfoPatcher is still using the old value.
Example with environment variable
Write-Host "##teamcity[setParameter name='env.Major.Minor.Patch' value='$version']"
Example with configuration parameter
Write-Host "##teamcity[setParameter name='Major.Minor.Patch' value='$version']"
Am I doing something wrong or is it just not possible? The only thing I want is that my files have the same version number as my TeamCity build...
The AsssemblyInfoPatcher runs before any of the build steps (and then runs again to revert your AssemblyInfo files after all your build steps). Thus, if one of your build steps sets Major.Minor.Patch using a service message, it's really too late to the game.
Maybe you could string multiple build configs together. The first config (A) would set up the parameter like you're doing now, and then trigger the second config (B), which would use the AssemblyInfoPatcher. B would have a snapshot dependency on A (in addition to the finish-build trigger) and thus its AssemblyInfoPatcher would be able to refer to %dep.A.Major.Minor.Patch%. This parameter, of course, would already be available when B's AssemblyInfoPatcher runs.

Arguments to PyUnit not parsed correctly

When we try to run a PyUnit test in Eclipse as a Python unit-test, it fails. This is because the arguments sent to PyUnit come in the following order: file-to-test --port portno. We have discovered that there is an environment variable called POSIXLY_CORRECT that, if set, makes PyUnit expect the arguments to come in a certain order, options first.
We have looked everywhere in Eclipse to try and find where these arguments are set, but are unable to find them. So as a workaround we change the run configuration to use an environment without the POSIXLY_CORRECT set. But this is very awkward.
Does anyone know how to solve this so that we do not need to modify the run configurations to be able to run our tests?

Show or log preprocessor macros during build

Is it possible to log or print preprocessor macros in XCode to the build results?
I want to see the current defined macros during a build.
For example if I have defined DEBUG and TESTSERVER as preprocessor macro there should be some lines in the build results like:
Compile Class.m ....
GenerateDSYMFile .....
Used macros: DEBUG, TESTSERVER...
Maybe there is custom shell script that could be executed after build.
OK I found the solution in the Apple documentation
Just enter a echo $GCC_PREPROCESSOR_DEFINITIONS to the run script build phase.
If you add a Run Script to the build phase and make sure "Show environment variables in build log" is checked it will print out all the environment variables for you. The run script can be empty and you will get a dump of all of the environment variables set for that current build. What you will not get is macros defined in header files.
To access the information once your project is built go to build results and expand the section "Run custom shell script " to view the values.
If you have set up Preprocessor definitions it will show on a line like this
setenv GCC_PREPROCESSOR_DEFINITIONS "DEBUG=1 Debug=1"