Here is is mentioned that there are three Sovrin Networks:
MainNet (prod)
StageNet (pre-prod)
BuilderNet (test)
But I can not find genesis files for those networks.
In sovrin github https://github.com/sovrin-foundation/sovrin/tree/master/sovrin
There are some genesis files but their names do not match with the nets above.
Where can I find the proper genesis files or mapping between the names?
Related
I've battled with this question for hours now, searching far and wide through the web finding several guides to setup testing for individual plugins which created new a installation of WordPress and created a new empty database as testing ground for said plugin.
However, what I wanted was to test all my plugins at the same time, as many have integrations with each other and have their own configurations already set in the database which would need to be re-inserted into the newly created test database.
So, I simply edited the file bin/install-wp-tests.sh as described below:
In the function install_wp() include the line at the end of the function: cp -a /$USER/wordpress/wp-content/. $WP_CORE_DIR/wp-content/
In the function create_db(), change content of function to:
mysqldump $USER_wordpress > dump.sql --user="$DB_USER" --password="$DB_PASS"$EXTRA
mysqladmin create $DB_NAME --user="$DB_USER" --password="$DB_PASS"$EXTRA
mysql $DB_NAME < dump.sql --user="$DB_USER" --password="$DB_PASS"$EXTRA
(Note: In my case $USER_wordpress is the name of the wordpress databse, and /$USER/wordpress/wp-content/ is the absolute path to wp-content.)
This way, the tests are made using your entire current installation of wordpress including all plugins you've installed or created, and the your current database data.
To load your plugins, you need to specify them on the function _manually_load_plugin() on the file tests/bootstrap.php, by including the plugin like so:
require rtrim( sys_get_temp_dir(), '/\\' ) . '/wordpress/wp-content/plugins/' . 'exampleplugin/exampleplugin.php';
I've used the following guides:
https://poweredbycoffee.co.uk/unit-testing-with-wordpress/
https://maheshwaghmare.com/wordpress/blog/phpunit-tests/
https://wpmudev.com/blog/unit-testing-wordpress-plugins-phpunit/
https://sanjeebaryal.com.np/fixing-issues-while-setting-up-php-unit-tests-for-wordpress-plugins/
But non of them answered the fundamental question of how to include all your plugins and database configurations for your tests, so you could test multiple plugins inside the same test and using all your plugin configurations already set inside you db.
u-boot support many platform. and there are files with same file name. it's hard to determine which file is involved in the make process for a certain platform. how could I get all files that be used in make process?
You could:
first, build u-boot for your target platform,
then look for all object files that resulted from the compilation process.
For example, if your u-boot main makefile were located in /opt/u-boot-2019.01,
the following commands would give you all the object files that were compiled:
cd /opt/u-boot-2019.01
find . -name "*.o"
You can then correlate the list of files you retrieved with the content of your target board's config file, usually located in the configs sub-directory.
In my case, the first object files to be displayed are:
./scripts/kconfig/zconf.tab.o
./scripts/kconfig/conf.o
./scripts/dtc/srcpos.o
./scripts/dtc/dtc.o
./scripts/dtc/treesource.o
./scripts/dtc/util.o
./scripts/dtc/fstree.o
./scripts/dtc/checks.o
./scripts/dtc/flattree.o
./scripts/dtc/dtc-parser.tab.o
./scripts/dtc/livetree.o
./scripts/dtc/dtc-lexer.lex.o
./scripts/dtc/data.o
./arch/arm/cpu/built-in.o
./arch/arm/cpu/armv8/built-in.o
./arch/arm/cpu/armv8/cpu-dt.o
./arch/arm/cpu/armv8/cache_v8.o
./arch/arm/cpu/armv8/generic_timer.o
./arch/arm/cpu/armv8/exceptions.o
./arch/arm/cpu/armv8/lowlevel_init.o
./arch/arm/cpu/armv8/fwcall.o
./arch/arm/cpu/armv8/cpu.o
./arch/arm/cpu/armv8/start.o
./arch/arm/cpu/armv8/cache.o
./arch/arm/cpu/armv8/transition.o
./arch/arm/cpu/armv8/tlb.o
./arch/arm/mach-sunxi/built-in.o
./arch/arm/mach-sunxi/clock.o
./arch/arm/mach-sunxi/dram_helpers.o
./arch/arm/mach-sunxi/pinmux.o
./arch/arm/mach-sunxi/prcm.o
./arch/arm/mach-sunxi/board.o
./arch/arm/mach-sunxi/clock_sun6i.o
./arch/arm/mach-sunxi/cpu_info.o
./arch/arm/mach-sunxi/rsb.o
For example, the fact that the file ./arch/arm/mach-sunxi/rsb.o is in the list means that ./arch/arm/mach-sunxi/rsb.c was compiled during the build process and contributed to the resulting u-boot image.
We have tried to migrate some SQL versions in a single database and it went well. When to tried to implement the migrations for multiple databases at the same time by passing multiple config files is failing.
The issue is it takes only the last config file and the migration is performed only for the database mentioned in the last config file, when passed the multiple config files in "-configFiles" parameter.
Below is the screenshot of the same, it took only flywayconfdb.conf file and left other files.
[oracle#localhost flyway-5.1.4]$ ./flyway -configFiles=/home/oracle/flyway/flyway-5.1.4/conf/flyway.conf,/home/oracle/flyway/flyway-5.1.4/conf/flywayjiradb.conf,/home/oracle/flyway/flyway-5.1.4/conf/flywayconfdb.conf info
Flyway Community Edition 5.1.4 by Boxfuse
Database: jdbc:oracle:thin:#//XXXXXXXXX:1521/confdb (Oracle 12.2)
Schema version: << Empty Schema >>
+----------+---------+-------------+------+--------------+-------+
| Category | Version | Description | Type | Installed On | State |
+----------+---------+-------------+------+--------------+-------+
| No migrations found |
+----------+---------+-------------+------+--------------+-------+
Please help us in resolving the same.
Flyway merges the config files. It doesn't do a separate migration for each one.
For each config file, Flyway adds the content to a Properties map. Properties has only one value per key, so if the same key appears in a second config file it would overwrite the previous value. This is why it seems like just the settings from the last config file are used.
It allows you to define some common settings somewhere, for example in ~/flyway.conf, which could be merged with some more specific settings, e.g. in individual projects.
But it doesn't allow you to migrate multiple databases in a single run. You need to run Flyway once per database:
./flyway -configFiles=/home/oracle/flyway/flyway-5.1.4/conf/flywayjiradb.conf info
./flyway -configFiles=/home/oracle/flyway/flyway-5.1.4/conf/flywayconfdb.conf info
The documentation describes the Overriding Order as:
Command-line arguments
Environment variables
Custom config files
<current-dir>/flyway.conf
<user-home>/flyway.conf
<install-dir>/conf/flyway.conf
Flyway command-line defaults
With settings defined higher up the list having greater precedence.
The documentation gives the following example:
The means that if for example flyway.url is both present in a config
file and passed as -url= from the command-line, the command-line
argument will take precedence and be used.
The Custom config files (-configFiles) lines could be expanded as:
Command-line arguments
Environment variables
Custom config file n
...
Custom config file 2
Custom config file 1
<current-dir>/flyway.conf
<user-home>/flyway.conf
<install-dir>/conf/flyway.conf
Flyway command-line defaults
And a corresponding example could be:
The means that if for example flyway.url is both present in custom config file 1 and custom config file 2, the custom config file 2 settings will take precedence and be used.
Similarly, if the flyway.url was also in custom config file n that would override that setting from custom config file 2.
I am attempting to make a migration from D7 to D8 using Migrate Manifest. I have all the migrate modules installed (i.e. the 3 core migrate modules, Migrate Upgrade, Migrate Plus, Migrate Tools and Migrate Manifest). I followed the directions at this link: https://www.drupal.org/node/2350651 to prepare my manifest file. This is the relevant part of my resulting yaml file (truncated for brevity):
- block_content_body_field
- block_content_entity_display
- block_content_entity_form_display
- block_content_type
- d7_block
- d7_custom_block
When I ran the migrate-manifest via Drush, as specified by the directions in the link above, I received an error declaring a parse error pointing to the first line in the yaml list. This is the exact error: Unable to parse at line 1 (near " - block_content_body_field").
I tried several debugging steps:
I checked a yaml linter to see whether my file was properly formatted. My file passed the test.
I moved the block migrations below the ones that are prefixed with a 'd7' to match the example in the link.
I attempted a piecemeal migration of a file from my list of migrations, it worked.
I tried to alter the spacing on the list items.
All these steps failed to resolve the issue I am seeing.
I am unsure what other debugging steps I should take. All the above failed to resolve my issue.
Any ideas would be appreciated.
I would like to store all Salt files (pillars, states, data files, etc.) in a git repository, so that this repository can be cloned on several different deployments.
Then I would like to be able to change the value of some pillar settings, such as a pathname, or a password, but without editing the original file which is in version control (i.e. those modifications would be local only and not necessarily versioned).
I would like to be able to pull new versions from the original repository (e.g. to add new pillar and state definitions) without losing the customized values.
E.g. the "base" or "default" pillar file would have settings like:
service:
dir: /var/opt/myservice
username: myuser
password: mypassword
and I would like to customize some settings, in another file, without changing the base file:
service:
dir: /mnt/data/myservice
password: secret_password
The modified settings should take precedence over the base / default ones.
Is it possible to do this by using environments (e.g. a "base" environment and a "custom" environment)?
Or perhaps by including these custom pillar files?
The documentation seems to indicate that there isn't a fixed order for overriding pillar settings.
Let me first suggest a way where you keep the original file and the customized settings in the git repository. See below how to override setting with a file outside of git.
Setup Git Pillar
I assume all files are stored in a git pillar like described here. I am using the syntax of salt version 2015.8 here.
ext_pillar:
- git:
- master https://gitserver/git-pillar.git:
- env: base
In your top.sls file you can list different SLS files. They will override each other in the order listed in the top file:
# top.sls
base:
'*':
standard
'*qa'
qaservers
'hostqa':
hostqaconfig
This will apply on all servers:
# standard.sls
test:
setting1: A
setting2: B
This will apply on all servers with the name ending with 'qa':
# qaservers.sls
test:
setting2: B2
This will apply to the server with the name 'hostqa':
# hostqa.sls:
test:
setting1: A2
The commands salt hostqa saltutil.refresh_pillar and salt hostqa pillar.data will then show that the values A2 and B2 as they have all been merged together.
As this works without specifying environments, I suggest not to use environments here.
Override some local settings outside of Git
To override some of your settings locally, you can add another external pillar. One of the most simple ones is cmd_yaml that will run a command (here: cat) and merge the output with the current pillar:
ext_pillar:
- git:
- master https://gitserver/git-pillar.git:
- env: base
- cmd_yaml: cat /srv/salt/local_override.sls
All external pillars are executed in the order listed in the configuration file.