xmlrpc.client.Fault when calling TestRun.update() - kiwi-tcms

Kiwi version 6.0, tcms-api 5.0.
Given that 82 is a valid test run_id and 7 is a valid build_id for the test run's product in the Kiwi instance, run this Python snippet:
from tcms_api import TCMS
kiwi = TCMS()
kiwi.exec.TestRun.update(82, {'build' : 7})
Expect:
The test run's product build is updated from 1 (unspecified) to 7.
Result:
Exception has occurred: xmlrpc.client.Fault
<Fault -32603: "Internal error: 'status'">
There's no other call stack information, so I'm at a loss to further debug. I've tried updating a couple of different fields (manager and status) with the same result. I also get the same result if the value I'm trying to update is unknown/invalid.
Additional information: the equivalent call to TestCaseRun.update() API works. I.e., I can update the build information on a TestCaseRun instance.

#s-manke. This is a genuine bug. I've implemented a hot-fix here: https://github.com/kiwitcms/Kiwi/pull/553
so you can at least continue to use the API.
I am in the process of cutting a new version anyway so this hot-fix will go in. However the API will not process status or stop_date fields at the moment.

Related

DSpace 7 - No suggestions when adding a new metadata field to an existing item

In DSpace 7.4, while adding new metadata to an existing item I'm not getting any suggestions in the input box, is there any configuration step I'm missing?
I can see it working in the official demo site
here
I see in dspace.log that there is this API call when I type something in the input box:
GET /server/api/core/metadatafields/search/byFieldName
so I tried this with no results:
/server/#api/core/metadatafields/search/byFieldName?query=author
The same API call in the DSpace 7 demo site returns 3 results: https://api7.dspace.org/server/#api/core/metadatafields/search/byFieldName?query=author
Also, in solr.log I see this call, which returns no hits:
2023-01-11 13:09:55.709 INFO (qtp359742806-22) [ x:search] o.a.s.c.S.Request [search] webapp=/solr path=/select params={q=*:*&fl=search.resourcetype,search.resourceid,search.uniqueid,database_status&start=0&fq=fieldName_keyword:author*&fq=&wt=javabin&version=2} hits=0 status=0 QTime=1
Maybe there is a problem with SOLR?
Since it seemed to be a SOLR problem, I tried to reindex like this: dspace index-discovery -b, thus getting this error:
java.lang.NullPointerException: Cannot invoke "org.dspace.eperson.EPerson.getID()" because the return value of "org.dspace.authorize.ResourcePolicy.getEPerson()" is null
at org.dspace.discovery.SolrServiceResourceRestrictionPlugin.additionalIndex(SolrServiceResourceRestrictionPlugin.java:95)
at org.dspace.discovery.indexobject.IndexFactoryImpl.buildDocument(IndexFactoryImpl.java:67)
at org.dspace.discovery.indexobject.InprogressSubmissionIndexFactoryImpl.buildDocument(InprogressSubmissionIndexFactoryImpl.java:46)
at org.dspace.discovery.indexobject.WorkspaceItemIndexFactoryImpl.buildDocument(WorkspaceItemIndexFactoryImpl.java:63)
at org.dspace.discovery.indexobject.WorkspaceItemIndexFactoryImpl.buildDocument(WorkspaceItemIndexFactoryImpl.java:30)
at org.dspace.discovery.SolrServiceImpl.update(SolrServiceImpl.java:165)
at org.dspace.discovery.SolrServiceImpl.indexContent(SolrServiceImpl.java:155)
at org.dspace.discovery.SolrServiceImpl.updateIndex(SolrServiceImpl.java:340)
at org.dspace.discovery.SolrServiceImpl.updateIndex(SolrServiceImpl.java:327)
at org.dspace.discovery.IndexClient.internalRun(IndexClient.java:130)
at org.dspace.scripts.DSpaceRunnable.run(DSpaceRunnable.java:104)
at org.dspace.app.launcher.ScriptLauncher.executeScript(ScriptLauncher.java:149)
at org.dspace.app.launcher.ScriptLauncher.handleScript(ScriptLauncher.java:131)
at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:98)
And found the solution here: https://groups.google.com/g/dspace-tech/c/ioukme4el9o.
WARNING: It's recommended to test this in a development environment first.
The problem is that there was several rows with no eperson_id and no epersongroup_id in the resourcepolicy table. So, I've deleted those rows with delete from resourcepolicy where eperson_id is null and epersongroup_id is null; and reindexed: dspace index-discovery -b.
Note: this problem seems to occur whenever the database comes from a dump of a previous DSpace version. In my case I restored a dump from a 5.6 version and migrated it to 7.4 before running into this issue.

Android Manifest merger error in Codename One

In a bare bones project, I added these build hints:
android.gradleDep=compile 'com.erikagtierrez.multiple_media_picker:multiple-media-picker:1.0.5'
android.min_sdk_version=23
I would like to import the following Android library to make a CN1Lib (that requires at least Android SDK 23):
https://github.com/erikagtierrez/multiple-media-picker
To be short: I spent one day trying to import that, I also experimented with Android Studio and with suggestions found on Stack Overflow (trying to make a custom .aar), without success.
Could you help me to import that library? There is manifest merger error.
In fact, the issue reported by the build server is:
* What went wrong:
Execution failed for task ':processReleaseManifest'.
> Manifest merger failed : Attribute application#label value=(BareBones) from AndroidManifest.xml:15:17-42
is also present at [com.erikagtierrez.multiple_media_picker:multiple-media-picker:1.0.5] AndroidManifest.xml:23:9-41 value=(#string/app_name).
Suggestion: add 'tools:replace="android:label"' to <application> element at AndroidManifest.xml:15:3-43:103 to override.
I also tried to add the build hint:
android.xapplication_attr=tools:replace="android:label"
as suggested by the previous error, without success.
In the last case, I get:
Merging result: ERROR
/tmp/build1659178556337293135xxx/Test/src/main/AndroidManifest.xml:15:3-43:103 Error:
tools:replace specified at line:15 for attribute android:label, but no new value specified
/tmp/build1659178556337293135xxx/Test/src/main/AndroidManifest.xml Error:
Validation failed, exiting
-- Merging decision tree log ---
The last full log is here: https://gist.github.com/jsfan3/dd6c23f86a2ac949f996910c8cece62b
Thank you
This is happening because our code things you injected android:label on your own and doesn't inject it to avoid collision...
Change the code to this:
android.xapplication_attr=tools:replace="android:label" android:label="App Name"

Akeneo 2.2.5: No JobInstance found with code "add_to_existing_product_model"

Since the forum at akeneo.com is locked down, I posted my question here.
When I try to add Produkts to a Product-Model via mass-edit, I get the following error message:
No JobInstance found with code "add_to_existing_product_model"
[2018-06-19 19:39:31] request.INFO: Matched route "pim_enrich_mass_edit_rest_launch". {"route":"pim_enrich_mass_edit_rest_launch","route_parameters":{"_controller":"pim_enrich.controller.rest.mass_edit:launchAction","_route":"pim_enrich_mass_edit_rest_launch"},"request_uri":"http://pim.eu-trading.eu/rest/mass_edit/","method":"POST"} []
[2018-06-19 19:39:32] request.CRITICAL: Uncaught PHP Exception Symfony\Component\Translation\Exception\NotFoundResourceException: "No JobInstance found with code "add_to_existing_product_model"" at ./vendor/akeneo/pim-community-dev/src/Pim/Bundle/EnrichBundle/MassEditAction/OperationJobLauncher.php line 59 {"exception":"[object] (Symfony\\Component\\Translation\\Exception\\NotFoundResourceException(code: 0): No JobInstance found with code \"add_to_existing_product_model\" at ./vendor/akeneo/pim-community-dev/src/Pim/Bundle/EnrichBundle/MassEditAction/OperationJobLauncher.php:59)"} []
I get this error with the latest version of Akeneo 2 (v2.2.5). The product model was created manually, the products to be associated with the model came through the api.
This error looks like a missing job in the database. Did you run all the doctrine migrations?
To do so you need to launch this command:
bin/console doctrine:migrations:migrate --env=prod
If you already launched the migrations and they failed, you can install a clean 2.2.5 PIM elsewhere and dump the job instance table to be able to add the missing jobs. Here is the list of the jobs to add or update in 2.2:
- add_association
- move_to_category
- add_to_category
- remove_from_category
- add_to_existing_product_model
- compute_family_variant_structure_changes
- compute_completeness_of_products_family
- add_attribute_value
- delete_products_and_product_models

Xcode 9.2 error

I've tried to launch an iOS debug build last friday (so after the Xcode 9.2 by default) and the build process failed with following message :
Error Domain=IDEFoundationErrorDomain Code=1 "exportOptionsPlist error for key 'iCloudContainerEnvironment': expected one of {Development, Production}, but no value was provided" UserInfo={NSLocalizedDescription=exportOptionsPlist error for key 'iCloudContainerEnvironment': expected one of {Development, Production}, but no value was provided}
** EXPORT FAILED **
Process return code is 70
I've fixed this by forcing build with 7.3, but is it a way to fix this error from my side ? I don't like the idea to not use the latest version if it's available.
How did you set up the App ID in Apple Developer. The settings should look like
Notice that is should be associated with zero cloud containers.

How to retry failed scenario in Behave using python

Can someone please tell me how I can run a failed test again in Behave using Python?
I want to re-run the failed test case automatically if it fails.
The behave library actually has a RerunFormatter which can help you rerun the failing scenarios of your previous test-run. It creates a text file of all your failing scenarios like:
# -- file:rerun.features
# RERUN: Failing scenarios during last test run.
features/auth.feature:10
features/auth.feature:42
features/notifications.feature:67
To use the RerunFormatter all you need to do is put it in your behave configuration file (behave.ini):
# -- file:behave.ini
[behave]
format = rerun
outfiles = rerun_failing.features
To rerun the failing scenarios, use this command:
behave #rerun_failing.features
I know that's a later answer but it could help others.
There is another approach that also could help, it's implementing it under the environment.py file, you could do the retry by a specific tag.
Provides support functionality to retry scenarios a number of times
before their failure is accepted. This functionality can be helpful
when you use behave tests in an unreliable server/network
infrastructure.
For example, I am running tag "#smoke_test" on CI, so I choose this tag to patch with retry condition.
First, on your environment.py import the following:
# -- file: environment.py
from behave.contrib.scenario_autoretry import patch_scenario_with_autoretry
Then add the method:
# -- file:environment.py
#
def before_feature(context, feature):
for scenario in feature.scenarios:
if "smoke_test" in scenario.effective_tags:
patch_scenario_with_autoretry(scenario, max_attempts=3)
*max_attempts are by default set as 3. I just described there to make it explicit that you can actually set how many retries you want.

Resources