I'm developing a new cloudify plugin that I test using tox, nosetests and #workflow_test decorator following the plugin template.
I'd like to test the plugin interacting with another plugin (speficially openstack plugin). Hence I'm using a blueprint that imports my plugin (test yaml file) and the openstack yaml file, and then defines some nodes from my plugin and from openstack.
The problem is that I'm getting module python import errors as the openstack plugin is not found in the test environment created by tox/nosetests. I tried installing the plugin using wagon before running nosetests, but the installation fails.
Anyone could indicate me how to do that?
Have you tried requirements files? In your tox.ini file, you should be able to define your test requirements like this:
[testenv:py27]
deps =
-rdev-requirements.txt
-rtest-requirements.txt
Then put either the URL of the branch zip (such as master) in your test-requirements.txt file:
https://github.com/cloudify-cosmo/cloudify-openstack-plugin/archive/master.zip
nose>=1.3
tox
In general, I find the workflow_test not to be very useful, and usually I end up writing something else for the same purpose. For example, these functions basically do the same thing in this test base:
https://github.com/cloudify-incubator/cloudify-ecosystem-test/blob/791f02a27313ac0b63b029c66ead333cb17c4d9c/ecosystem_tests/init.py#L100
https://github.com/cloudify-incubator/cloudify-ecosystem-test/blob/791f02a27313ac0b63b029c66ead333cb17c4d9c/ecosystem_tests/init.py#L151
https://github.com/cloudify-incubator/cloudify-ecosystem-test/blob/791f02a27313ac0b63b029c66ead333cb17c4d9c/ecosystem_tests/init.py#L225
Related
I know the export and import option is available but I have 5 environments, So each and every time after implementing new things on dev env I don't want to do export and import on other envs instead using pipeline I will execute the drush commands to implement the required changes on other envs by executing required Drush commands.
The problem is that on Drupal the config import/export is the best way to do that.
The config export doesn't not only export content type configuration, but the entire website configuration.
So thoses commands help you be iso between environments.
If your probleme is about ouverriding some config values between environments, the module Config Split can help you on it.
With no config import, I would solve it with installing a module of your own, which runs your special code.
Steps:
Create a module my_custom_contenttype
Make a hook_install() (my_custom_contenttype_install())
Run this drush command (uninstall before, if you want to install it again - do it more than one time):
drush pm:uninstall my_custom_contenttype; drush pm:enable my_custom_contenttype;
function my_custom_contenttype_install(){
// Add content type if it not exist
};
You could do this using manually-managed configuration. Either by:
Creating a custom module and including your configurations in custom_module/config/install, and using "drush en" to install the module
OR
By using an existing custom module and using a post_update hook to install the configuration.
We do this on a number of sites, and loading and installing the configurations is just complex enough that we built a helper module to do it. You can pull this module in with composer and use update hooks to activate it, or you can look at the installConfig function here and use it a as a template. (the module has a helpful readme, too).
I am trying to troubleshot an error I'm getting in Blazemeter for random-csv-data-set.
The btz.log from the Blazemeter Test run shows the below line...
2021-02-10 10:14:52,518 INFO o.j.r.JARSourceHTTP: Downloading: https://search.maven.org/remotecontent?filepath=com/blazemeter/jmeter-plugins-random-csv-data-set/0.7/jmeter-plugins-random-csv-data-set-0.7.jar
Which could be the point it downloads the jar (latest one?) for the required plugins for my test.
And during the test I am getting an exception from one of the classes in the plugin jar.
I have cloned the plugin project (opensource) and started adding some debug lines and compiled a new jar version.
I was advised If I upload the plugin jar along with my tests files to Blazemeter, the uploaded jar should be taken in for the run. But I still see the exception from the old line numbers which means its still referring to the original jar version 0.7.
How can I override this with my version of the plugin?
I believe you should ask this type of questions via BlazeMeter Support as I doubt that everyone here is fully aware of what's going on there
Whatever.
Looking into Taurus documentation it looks like that Random CSV Data Set Config is being detected and automatically downloaded using JMeter Plugins Manager so in order to prevent Taurus from downloading the "vanilla" version of the plugin which doesn't contain your changes you need to add the following line to your Taurus YAML file:
modules:
jmeter:
detect-plugins: false
I'm using SBT native packager 1.2.0-M3 for packaging a Play Framework 2.5.3 application as an RPM (targeted for RHEL 7 with systemd). I would like to change the behavior of the generated RPM such that it does NOT automatically start after install but is being enabled (systemctl enable <name>.service).
I've been following the instructions outlined at http://www.scala-sbt.org/sbt-native-packager/archetypes/java_server/customize.html. Specifically, I created a file src/rpm/scriptlets/post-rpm containing a single line systemctl enable <name>.service. As far as I understand the documentation, that's all that is required. However, on installation of the RPM the service gets still automatically started. Is there any additional configuration required?
This is currently the default behaviour. There is a historical explanation here.
What you actually need to do are the maintainerScripts in Rpm.
There is a helper trait which lightens the build definition. Something like
import RpmConstants._
maintainerScripts in Rpm := {
(maintainerScripts in Rpm).value += (
Post -> "systemctl enable <name>.service"
)
}
And there is a feature request to implement this in native-packager directly.
Calling grunt-eslint causes a Cannot find module 'eslint-plugin-react' error that doesn't happen when calling eslint directly from the command line.
I have eslint-plugin-react installed globally.
Is there an easy way to make grunt eslint behave the same way as eslint?
Assuming you don't want to install the node module locally for some reason, I can think of two options. 1. Use grunt-exec within your grunt file to run eslint, or 2. As per the answer in the link below setup a symbolic link to your global node modules folder:
How to use grunt-html installed globally?
When I set up a multilingual DjangoCMS powered website the default language code is appended to the URL:
http://mypage.com/ -> http://mypage.com/en
I don't want this to be the case for the default language (e.g. 'en') Instead what I want is the default language being chosen when there's no language identifier within the URL:
http://mypage.com -> Choose English
http://mypage.com/fr -> Choose French
http://mypage.com/it -> Choose Italian
How can this be done?
Versions:
Django CMS 3.0.3
Django 1.6.5
Python 2.7
I wrote this for a project that's currently using it in production, they use django-cms 2.4.3 but I don't see why it would not work on 3.0, all you need to do is create middleware.py file in one of your apps, say core and then replace django's locale middleware with the path to this one, since it's a subclass of it.
I faced a similar situation for a web site based Django CMS version 3.4.5 and Django version 1.8.18. At first sight this seems to be a Django CMS concern, but later I realized this is more related with core Django, which has been natively addressed by the recent versions of this project.
A working solution
The straightforward solution I applied involved these changes:
Upgrade to Django version 1.11.8 (any version >= 1.10 should work). A shell command like pip install Django==1.11.8 --upgrade can achieve this.
Edit the urls.py file to change it like the following:
Original content of urls.py file:
urlpatterns += i18n_patterns(
url(r'^admin/', include(admin.site.urls)), # NOQA
url(r'^', include('cms.urls')),
)
New content of urls.py file:
urlpatterns += i18n_patterns(
url(r'^admin/', include(admin.site.urls)), # NOQA
url(r'^', include('cms.urls')),
prefix_default_language=False
)
Apply Django migrations, which are part of the new version of Django
Run again the Django project and visually verify the new desired behavior
I should mention that someone with the nick FalseID at the #django-cms IRC channel gave me the advice to find this solution, as well as other related tips.
Other references
Existing answer that applies to a general Django project https://stackoverflow.com/a/43911714/6693126 if the version of Django is >= 1.10. This describes a similar situation to mine.
For Django versions < 1.10, this answer is useful: https://stackoverflow.com/a/17517000/6693126 which is based on the django-solid-i18n-urls package. I have not tested this procedure, but it should work.