The Rails Team introduced a new way to handle secrets in the application using a new concept called credentials (http://weblog.rubyonrails.org/2017/9/23/this-week-in-rails-new-credentials-configuration-bugfixes-and-more/).
To encrypt and decrypt the credentials files you need the master.key file. I'm running my test suite using CircleCI but the master.key is not available in the github repository and therefore CircleCI can not build the application correctly.
What is the best way to handle this situations in CircleCI?
According to the release notes the key can either be in a key file or an environment variable called RAILS_MASTER_KEY
Under settings in CircleCI you can go Build Settings > Environment Variables and place the key there.
Related
I am working on setting up CI/CD for my organization. I am trying to build an automated system that will deploy our changes to our Shopify theme when we push to a branch.
I have a config.yml file that contains information like password, themeID and so on. I am trying to find a way to hide these variables in our repo. Github secrets have not seemed to work, as I can't figure out how to pass those secrets from my workflow yaml file to my root level config.yml file. Any help would be greatly appreciated!
I have a react native application built and distributed through microsoft appcenter. for the iOS side, I have a release variant which is the live production variant. and i have a staging variant. the git flow im trying to achieve is something like this:
create feature branch from either master or staging (for the sake of
this argument) -->
push OTA update to staging variant -->
merge staging variant into master (this is the key part)
I want to be able to merge staging into master without having to manually set the defaultConfigurationName each time i pull staging into master, or push the master-branched-feature-branch to staging. I want a dynamic value: master's value to always be 'release' and staging to always be 'staging'.
Problem:
When merging staging branch into master branch (production), the defaultConfigurationName in project.pbxproj changes the variant that will be built by microsoft appcenter from the release variant (production) to the staging variant
lets say i have an env variable called "ENVIRONMENT", with values of 'release' and 'staging', corresponding to 'master' and 'staging branches. i want to automate management of the ios build configuration when merging staging into master, and not have to manually reset defaultConfigurationName back to 'release' each time i merge staging into master. how can i set the env variable's value to the value of "defaultConfigurationName" in project.pbxproj file?
Note: i dont need help setting up environments or environment variables. i also dont want to create an additional target.
I came across this issue and found that you can update the info.plist file found in ios/app/app/info.plist to include your environment variables.
Eg
<key>CFBundleVersion</key>
<string>$(CAPACITOR_BUILD_NUMBER)</string>
Please have a look at this blog post, it shows how to set up multiple environments for android and iOS.
I've been using AWS amplify to build my iOS app's backend.
I have created 4 DTAP environments in the backend, with 4 different configurations, and use a run-script to switch in the correct versions of awsconfiguration.json and amplifyconfiguration.json at compile-time based on the selected scheme.
Since these auto-generated config files contain a number of secrets and API keys, I am keeping them away from source control in my .gitignore as this would be a point of failure, and I don't want to expose my entire backend in this way.
This works fine locally, but when I run my CI on Bitrise, the build fails since these config files aren't present. I need to find a way to get these AWS and Amplify config files into the CI to be able to create my test builds.
If I am being overly cautious, and the config files are actually fine to keep in source control (i.e. not secret), please let me know. I really don't want to set up secrets as individual environment variables, since Amplify will have several secrets and endpoints for each environment I need, and it feels too messy and complicated to have a script building these config files as a CI stage.
Things I've tried:
Creating mock config files with fake secrets that is copied in at compile time - this fails because the compile-time script still tries to copy the non-existent config files for the real environment
Using individual environment variables as secrets in Bitrise - this is likely to work, but will be a monumental effort for my 1-dev startup to maintain
Touching a fake config file to copy over - this works but means the actual AWS infra doesn't work in the test builds
I'll be grateful for any thoughts, suggestions or experience anyone has.
Thanks
Jacob
I would recommend using Generic File Storage and the related step to download them. This will inject them into your build and you will be able to put them where they need to be before the project is compiled.
I have a public Github project which uses Firebase, so it needs a GoogleService-Info.plist file. Since this file includes a bunch of API keys and such, I added the file to .gitignore
Today I set up Bitrise.io for CI purposes. Adding the project went just fine but now every time I trigger a build (or push to master), the build fails since the GoogleService-Info.plist is obviously missing from the repo.
Is there any kind of workaround to still hide the .plistfile from Github but expose it to Bitrise?
Use Secrets or Generic File Storage (https://devcenter.bitrise.io/tutorials/how-to-use-the-generic-file-storage/) in the Workflow editor.
There's just one limitation, that as your app is a public one on bitrise.io those secrets won't be available in Pull Request builds. But based on what you wrote that shouldn't be a problem, you don't want to expose it for anyone who can send a PR.
Note: if you'd store it as a Secret, then you can just write it into a file via a simple Script step: echo "$MY_PLIST_SECRET" > ./path/to/file.plist
I have a console application where I need some ideas on how to build/release the config part of the application. When running locally in VS the config file is called app.config. After a build the file changes to .exe.config. We are using XDT transformation for building the config file to the different enviroment. But what would be the smartest way to ensure the naming convension is correct when release the build version to a server?
Seems you want to use TFS Build and deploy to multiple environments via Release Management.
For handling configuration in Release Management, there are two techniques generally used Config Per Environment and Tokenization.
If you prefer a clean separation between build and deploy. To achieve that, recommend tokenizing configuration.
More details please take a look at this wonderful blog: Config Per Environment vs Tokenization in Release Management
Environment specific application settings values configured in the app.config are tokenized. Above blog's method essentially inserts tokens into setting values during the build process. When deployed the tokens are replaced with matching Release definition configuration values.
Besides, for an example of a separate build and release solution, you could also take a look at this blog: Using web.config transforms and Release Manager – TFS 2017/Team Services edition (similar to app.config)