Is there mechanism to import local settings to codeception.yml configuration file?
Our developers have their own databases and maybe some other environment specific settings for the testing, so these settings shouldn't be pushed to GIT. Normally we solve this problem by having two configuration files, where other one is global & in GIT. Another, local one is merged in some way or another to global one and ignored by the git. What I like to achieve would be following structure:
codeception.yml - global settings
codeception.local.yml - local settings witch would be merged to global settings e.g. by the import
There is a include property for config files, but it seems to deal with complete testing suites.
Yes actually. I can't find anything the manual about it, so I dug through the source code and it looks like it reads both codeception.yml and codeception.dist.yml files.
I tested it out it looks like codeception.dist.yml is your global config, and codeception.yml is what you should use for your local and put into .gitignore. Same goes for the suite.yml files. acceptance.suite.dist.yml is the global that gets overwritten by acceptance.suite.yml, etc etc.
Related
I've been searching for a solution but I can't find one.
I have a global configuration directory in my IntelliJ workspace. I also have several dozen modules. I would like each module to automatically include the global config directory in its path when I run or test a class.
Is there anyway to do this within IntelliJ? I don't think I should need to edit the configuration for each "Run/Debug" config to include the directory.
You'll want to set it in the Defaults for the type of Run or Debug Configuration that you are using.
For example, if I always want a Java Application to have the VM Option -XPutYourThingyHere, then I could go to Edit Configurations, Defaults, Application, and put -XPutYourThingyHere in the VM Options box. Then all new Applications that I run will have that option.
I would like all developers on my team to use the same default code style settings. We all use IntelliJ 11+ as our IDE and we use git as our source control system.
What is the easiest way to make sure they're all using the same settings? I thought there would be a way to check in the style settings into the project and have their editors discover them automatically, but that doesn't seem to be the case.
PS. I don't mind if developers consciously override some of the default settings with their own preferences, but I do want to make sure that we all at least start from a common set of default settings.
Code Style can be copied to project and saved in .idea/codeStyles to be shared via version control:
Copy to Project Click this button to create a copy of the current global scheme to the project level. After creating the copy, IntelliJ
IDEA suggests to switch to this new scheme at the project level.
The Settings Repository feature was introduced at IntelliJ IDEA 2016.
This option helps us to share IDE settings between different computers, including sharing settings between developers.
The settings are stored at Git repository, for example on GitHub or Bitbucket.
To setup Git repository we should set URL via Settings Repository menu option.
The developer can load remote settings, overwrite remote settings or merge local settings with remote ones.
The structure of Git repository with settings:
I used personal access token for GitHub authentication.
More information:
Settings Repository
Creating a personal access token for the command line
I came across this long after the fact, but thought I'd share if anyone ran into this. Add the following to your .gitignore
# IDE - IntelliJ
/.idea/*
# Keep the code styles.
!/.idea/codeStyles
/.idea/codeStyles/*
!/.idea/codeStyles/Project.xml
!/.idea/codeStyles/codeStyleConfig.xml
# Keep the inspection levels
!/.idea/inspectionProfiles
/.idea/inspectionProfiles/*
!/.idea/inspectionProfiles/Project_Default.xml
And of course, make sure your .gitignore also has a ! in front of it so these changes get picked up.
Basically, gitignore's recursive looking is a little wonky, so the below ignores a directory's contents, except for a subdirectory, then ignores that subdirectory's contents, except for the files we want.
codeStyleConfig lets you use per project settings, the project file itself is your actual code styles, and I included the Project_Default as it holds the warning levels, which you likely want if you're doing the code style work anyways.
You can create .editorconfig file in Your project (and it can be managed on directory level). More info on https://www.jetbrains.com/help/idea/configuring-code-style.html#editorconfig and https://editorconfig.org/
With this approach You can keep all Your code style settings in one file and it's not limited to IJ only.
I'm trying to make my project OSS, and I'd like to remove any sensitive info from the configs. I'm trying to have ENV['DB_PASS'] = mypassword. Where would I set this? I've tried export DB_PASS=mypassword in my .bashrc file. But that's not working.
Are you sure export isn't working? Have you tried echo $DB_PASS? (Also, changes to .bashrc won't take effect until the next time you log in.)
A more common way to handle this problem is to create a separate config file that is not tracked in your repository, and then provide a config.sample file demonstrating the common configuration options but with dummy values.
We are trying to setup stylecop for a team development environment. So far what we have done is:
Checked the files into source control
Create an environment variable on every machine that points to that location (each dev has source checked out to a different location, this solves that)
Add the tag to the project as follows:
This works great, but VS complains that the file is unsafe, and I know to fix that we have to mark is safe in the registry. We wanted to create a .reg file to import this setting and make it easier for everyone. Can we use that environment variable in the path? I have tried the snippet below, but that doesn't seem to work. Is the syntax for an environment variable different?
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports]
"StyleCop.4.3"="%StyleCopLocation%\\Microsoft.StyleCop.Targets"
Why you need to host that Targets file in a global place? Everyone can install a copy of StyleCop.
If you in fact plan to share StyleCop settings, please configure the projects to use a project locally setting file (*.SourceAnalysis). You can check in this file along with your projects, and then everyone is in sync.
I have a project where I create a JAR which contains a bunch of classes with main() plus a set of scripts which set the environment to invoke them. Most of those are long running processes which log a lot (~10-20GB).
This means I have a pretty complex log4j.xml file which, being in src/main/resources/, goes into the JAR. When something breaks in the production system, I'd like to modify the logging on the fly for a single run.
So I came up with the idea to have a conf/ directory on the production and put that into the classpath, first. Then, I thought that it would be great if M2 would put the config files in there (instead of the JAR). But that would overwrite any manual changes during an automated deployment which I strongly dislike. I'm also not fond of timestamps and things like that.
So my next ideas was this: M2 should leave the config files in the JAR but create copies of the files with the name *.tpl in the conf/ directory. The admin could then copy a template to the basename to override the files in the JARs. .tpl-Files would be overwritten but that wouldn't hurt. Admins would have full control over which version of the log was active and they could run a diff to see whether any important changes were made.
Now the question: Has someone seen a plugin which automates this process? That is which creates a conf/ directory with all or a selected subset of everything in src/main/resources/ and which renames the files?
Best practice in Maven handling config files is to place them in a separate conf directory, and pack them in a binary assembly using the assembly plugin. Placing configuration files, like log4j.xml in the src/main/resources doesn't make sense, since it is not a true application resource, but more of a configuration file.
We cope with the overwriting, by packing the configuration files with the posfix .def. For example: myapp.properties is packed into the assembly as myapp.properties.def. When the person who uses the assembly unpacks it, it will not overwrite his original files. After unpacking he simply merges them by an external tool (we use meld in Fedora Core).
I may be missing something and this doesn't answer directly the question but did you consider producing a zip assembly of the exploded content of required artifacts (to be unzipped on the target environment)?
Sounds like you're attacking the problem the wrong way. Why not just run the application with -Dlog4j.configuration=/some/where/my-log4j.properties? If you want, you can add a command line flag to main() which invokes the PropertyConfigurator directly.