Im looking to use Playwright on python/pytest to test against a web page.
The system im working on has 3 different environments that we need to deploy against,
for example https://env1.com, https://env2.com, https://env3.com
The first question is how do I target the different Environment? In my pytest.ini I had a --base-url parameter but I need to override that.
In addition each environment has different login credentials, how can I create and override these as parameters per environment?
Related
Please note, although my specific example here involves Java/Grails, it really applies to any type of task available in Bamboo.
I have a task that is a part of a Bamboo build where I run a Java/Grails app like so:
grails run-app -Dgrails.env=<ENV>
Where "<ENV>" can be one of several values (dev, prod, staging, etc.). It would be nice to "parameterize" the plan so that, sometimes, it runs like so:
grails run-app -Dgrails.env=dev
And other times, it runs like so:
grails run-app -Dgrails.env=staging
etc. Is this possible, if so, how? And does the REST API allow me to specify parameter info so I can kick off different-parameterized builds using cURL or wget?
This seems to be a work around but I believe it can help resolve your issue. Atlassian has a free plugin call Bamboo Inject Variables Plugin. Basically, with this plugin, you can create an "Inject Bamboo Variables from file" task to read a variable from a file.
So the idea here is to have your script set the variable to a specific file then kick off the build; the build itself will read that variable from the file and use it in the grails task.
UPDATE
After a search, I found that you can use REST API to change plan variables (NOT global). This would make your task simpler: just define a plan variable (in Plan Configuration -> tab Variables) then change it every time you need to. The information on how to change is available at Bamboo Knowledge Base
In particular, for test-cases, I want to keep the test database separate so that the test cases don't interfere with development or production databases.
What are some good practices for separating development, test and production environments?
EDIT1: Some context
In Ruby On Rails, there are different configuration files by convention for different environments. So does Play! 2 also support that ?
Or, do I have to cook the configuration files, and then write some glue code that selects the appropriate configuration files ?
At the moment if I run sbt test it uses development database ( configured as "default" in conf/application.conf ). However I would like Play!2 to use a different test database.
EDIT2: On commands that play provides
For Play! 2 framework, I observed this.
$ help play
Welcome to Play 2.2.2!
These commands are available:
-----------------------------
...OUTPUT SKIPPED...
run <port> Run the current application in DEV mode.
test Run Junit tests and/or Specs from the command line
start <port> Start the current application in another JVM in PROD mode.
...OUTPUT SKIPPED...
There are three well defined commands for "test", "development" and "production" instances which are:
test: This runs the test cases. So it should automatically select test configuration.
run <port>: this runs the development instance on the specified port. So this command should automatically select development configuration.
start <port>: this runs the production instance on the specified port. So this should automatically select production configuration.
However, all these commands select the values that are provided in conf/application.conf. I feel there is some gap to be filled here.
Please do correct me if I am wrong.
EDIT3: Best approach is using Global.scala
Described here: How to manage application.conf in several environments with play 2.0?
Good practice is keeping separate instances of the application in separate folders and synching them i.e. via git repo.
When you want to keep single instance you can use alternative configuration file for each environment.
In your application.conf file there is an entry (or entries) for your database, e.g. db.default.url=jdbc:mysql://127.0.0.1:3306/devdb
The conf file can read environment variables using ${?ENV_VAR_NAME} syntax, so change that to something like db.default.url=${?DB_URL} and use environment variables.
A simpler way to get this done and manage your configuration easier is via GlobalSettings. There is a method you can override and that its name is "onLoadConfig". Try check its api at API_LINK
Basically on your conf/ project folder, you'll setup similar to below:
conf/application.conf --> configurations common for all environment
conf/dev/application.conf --> configurations for development environment
conf/test/application.conf --> configurations for testing environment
conf/prod/application.conf --> configurations for production environment
So with this, your application knows which configuration to run for your specific environment mode. For a code snippet of my implementation on onLoadConfig try check my article at my blog post
I hope this is helpful.
I want to use jenkins to deploy various WARs using our single script for multiple servers.
Could you please suggest how to pass servers name to a job, so that our script can take that as an argument and start deploying on the selected server? The solution will be used to deploy the same code to 10-20 servers using our customized ant script to build these projects.
EDIT: We are using AIX servers. Want to use a drop down menu from which user can select environment IP,Port. How should I approach this?:
Maintaining txt files of environments
Using choice parameter
On selection of this env, we will use this env variable in our shell script to deploy.
To have one job start another, just use the parametrized trigger plugin. In addition, I like to run the deployment jobs on the target machine. For this I defined a slave for every target server. To be able to run a job on a specific slave and be able to choose the slave as a parameter, I use the NodeLabel Parameter Plugin.
If you want more specific tips, be more specific on what application servers you use. It would also be interesting to know if you operate under windows, linux, or other environment. The more info you give the better and more fitting the answers.
We have a GWT Application that has to link another Application.
This link is different in all stages of my application (local, test, staging, prod). What options are there to configure a GWT app?
Currently we're using properties files for every environment. The problem with this solution is, that we have to create different packages for all the environments. That's bad and we want to build one single package that is deployable to all environments.
But how can we tell the application which configuration to use?
If you are lord of the rings fan -
One Build to rule them all, One Build to find then,
One Build to work on all and in the environment bind them
In the Land of Testing where the Shadows lie.
Solution at our workspace
All the environment specific properties file are pushed into template folder ( log4j_prod.properties,log4j_stage.properties, hibernate.properties etc )
Prod properties file are default and pushed to WEB-INF/classes
QA team modifies the property files using the template files for any other environment.
I too would be curious if it is done any other way :)
If you want to know weather the application is running in which mode , there are some static methods in GWT class .
isClient()
Returns true when running inside the normal GWT environment, either in Development Mode or Production Mode. Returns false if this code is running in a plain JVM. This might happen when running shared code on the server, or during the bootstrap sequence of a GWTTestCase test.
isProdMode()
Returns true when running in production mode. Returns false when running either in development mode, or when running in a plain JVM.
isScript()
Determines whether or not the running program is script or bytecode.
etc....
Based upon tha flags you can configure the folder name of the properties
I'm using CassiniDevLib to host an MVC app for integration testing.
In order to do it I need to amend some config settings on the web server so they match the integration testing environment, first one being the connection string so it points to the test database.
I know I can have two copies of the web.config file and rename them but I was wondering if there was a more elegant way. ie a way to amend the settings in code as part of the Test Fixture setup. The challenge being that I need to access the web server process from my test ficture process
Would appreciate any thoughts on this.
I assume that you are using Visual Studio 2010. In that, you have a feature called as Config Transforms. Basically you can have multiple config file for each build environment. You can have your own custom build env. You have a new one by going to Configuration Manager and adding a new one.
http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
you can search on the internet for Config Transforms, if you need more examples.