We use CircleCI to build our PHP app prior to deployment. One of the requirements in composer is a module stored in a private repository on Bitbucket.
Currently we store the credentials inside composer.json which is far from ideal.
The problem is that I can find no better solution for managing these credentials for repo access during the build. I'm assuming I can use an environment variable or similar.
The environment variable COMPOSER_AUTH is available to pass any number of authentication methods to composer and allows any keys or secrets to be managed outside of the repo.
In my example, to authenticate with bitbucket, the var looked like this:
export COMPOSER_AUTH='{"bitbucket-oauth": {"bitbucket.org": {"consumer-key": "xxxxxx","consumer-secret": "xxxxxx"}}}' (see: documentation)
CircleCi (and I'd assume most CI apps) has an environment variable settings page. Add the variable and value there and then you can remove the entire "bitbucket-oauth" block from composer.json.
Related
I'm trying to setup multiple environments for my Vue / Firebase Project.
I have two Firebase Projects
1.) Dev
2.) Prod
The project utilizes Stripe Extension which pulls the API Key from an auto-generated file called:
firestore-stripe-payments.env
which contains:
STRIPE_API_KEY=projects/${param:PROJECT_NUMBER}/secrets/firestore-stripe-payments-STRIPE_API_KEY-xxxx/versions/latest
Where xxxx is a random 4 character string.
That line pulls the value of the key from Google Secret Manager.
Let's say Dev is 'dddd'
and Prod is: 'pppp'
The issue is that I can only define either:
firestore-stripe-payments-STRIPE_API_KEY-dddd
or
firestore-stripe-payments-STRIPE_API_KEY-pppp
At first I tried to create a new value within Google Secret Manager simply called:
firestore-stripe-payments-STRIPE_API_KEY
The thought was this should be a simple fix, and it would pull the associated API_KEY for the project currently being used.
but this causes the error:
Error: firestore-stripe-payments: Found 'projects/foo/secrets/firestore-stripe-payments-STRIPE_API_KEY/versions/latest' for secret param STRIPE_API_KEY, but this instance was previously using a different secret projects/fooo/secrets/firestore-stripe-payments-STRIPE_API_KEY-dddd.
Changing secrets is not supported. If you want to change the value of this secret, use a new version of projects/foo/secrets/firestore-stripe-payments-STRIPE_API_KEY-dddd.You can create a new version at https://console.cloud.google.com/security/secret-manager?project=fooo
Also, if there is a better place to ask this question please let me know, couldn't find the 'right' room
For this scenario, could you include a separate env (env.dev) file using the following guidelines
.env # loaded in all cases
.env.local # loaded in all cases, ignored by git
.env.[mode] # only loaded in specified mode
.env.[mode].local
For generating separate keys for each environment, I believe from your example you are using a single Stripe Extension on a single project.
Firebase Extensions can support multiple instances of an Extension per project, this will create a separate "dev" secret for you to use.
Additionally, a separate Firebase project with another "Stripe Extension" installation would be recommended to separate any concerns in development.
Most of our client projects have a very similar starting point:
Pristine AWS account used only for a single environment for this application
GraphQL API and a basic model to start with
A REST API with an OAuth handler endpoint and a generic webhook listener endpoint, each with a corresponding Lambda function (with code for each)
I've created this basic amplify app and I want to create a repo with this general structure as a starting point for future projects. The idea being that I'd copy the contents of the repo when starting a project and build from there.
So I've copied the entire amplify directory over to a new location, removing everything that is in the amplify section of the .gitignore file, and I have a folder structure like this:
My steps to start a new project are:
Create a new directory
Copy the template repo files into this directory
run amplify init
Once I do that, it creates two additional files:
amplify/.config/project-config.json
amplify/team-provider-info.json
Then, I try to do amplify push -- but I get No changes detected.
I'm not even sure if what I'm doing is possible -- I was wondering if anyone else has tried this?
I have created and published API's using API manager 2.6.0 now I need to push these changes to another environment like system & UAT testing environment.
Can someone help me on how I can configure any repository to push the APIs created using API manager and move from one environment to another. I checked few sites related to WSO2 migration and CI/CD implementation but I could not able to do that properly so I am looking for high level explanation to use repository and migration to different environments.
You can export and import APIs from different environments using the migration APIs or the CLI tool:
Export API as seen here: https://docs.wso2.com/display/AM210/Migrating+the+APIs+to+a+Different+Environment
Export CLI as seen here:
https://docs.wso2.com/display/AM260/Migrating+the+APIs+to+a+Different+Environment
The exported APIs are a set of json and xml files that can be templated, and unless your APIs endpoints in other environments are the same as your development one, you will have to modify the exported APIs jsons and xmls to fit the other enviroment's data.
The best way to set up a repository, will be then to:
Export from your development environment the API to a local machine
Create a template out of it to be used with your favorite template deployment engine
Upload this templates to a repository manager (nexus, artifactory...)
Write the script to fill the template for each environment,
Create another script to call the APIM import CLI or API to import the filled template to each enviroment.
This is all best done within some CI/CD pipeline.
I want to use symfony-cmf/simple-cms-bundle in symfony3.2 but It's support only symfony2. So I am looking to avoid check version at the time of development and will update on production.
Is it possible by pass validation through any configuration or command for temporary basis into composer or any other place.
I'm using Travis for continuous integration. However, my projects depend on a private Nexus repository. I would rather not check in sbt credentials into our repository. Travis does support encryption keys but they only affect environment variables.
How can I get Travis to authenticate against Nexus? sbt does not seem to support credentials from an environment variable.
https://github.com/sbt/sbt/blob/0.13/launch/src/main/scala/xsbt/boot/Update.scala#L56
There looks like there is support to specify a credentials file from an environment variable, or to specify credentials as system properties. Unfortunately, this didn't seem to work with 0.13.
sbt -Dsbt.boot.realm="Sonatype Nexus Repository Manager" -Dsbt.boot.host="www.there.com" -Dsbt.boot.user="deployment" -Dsbt.boot.password="password" aether-deploy
You want to use Travis secure environment variables as documented. Assuming your environment variables are NEXUS_USER and NEXUS_PASS, the command line needs to be:
sbt 'set credentials += Credentials("Sonatype Nexus Repository Manager", "www.there.com", System.getenv("NEXUS_USER"), System.getenv("NEXUS_PASS"))' aether-deploy
You could also safely have that line in your build.sbt, if you wanted to make that a standard practice for your builds.
The Jackson Scala Module uses this for deploying Travis builds to the Sonatype OSS repository. You can our .travis.yml to see how it's set up.
You can set global variables in your .travis.yml as defined here:
http://docs.travis-ci.com/user/build-configuration/#Set-environment-variables
Those global vars can be encrypted for travis using the travis gem. Explained e.g. here:
How to use travis-ci's .travis.yml to provide environment parameters for Node.js Application?