Planned release for CREDIT MANAGEMENT functionality

Hi, I've been tracking the planned release for new Credit Management functionality, which was supposed to be being released in Jan 2020..... BUT checking today I see the feature has disappeared from the list of planned released Oct '19 - Mar '20.
Please advise on what is going on with this planned new functionality.
Regards,
Steve

PS: the site I've been monitoring is here: https://docs.microsoft.com/en-gb/dynamics365-release-plan/2019wave2/dynamics365-finance-operations/credit-management


flux_led not working in HA 0.88.0

Home Assistant release with the issue:
0.88.0
Last working Home Assistant release (if known):
0.87.1
Operating environment (Hass.io/Docker/Windows/etc.):
Hassio
Component/platform:
flux_led
Description of problem:
since update to 0.88.0 flud_led is no longer working
configuration.yaml

Additional information:

I have the same issue.
I am running Hass on docker on Ubuntu.

I also have the same issue, wrote about it here:
https://github.com/home-assistant/home-assistant/issues/21178


Plugin uses deprecated extension API version 1.0 (removed in GoCD 23.2.0)

Hiya @szamfirov  - GoCD maintainer courtesy call here. 👋
It seems this plugin is using the 1.0 extension API for authorizations.
https://github.com/szamfirov/gocd-okta-oauth-authorization-plugin/blob/c05e9a80027d5f481f34020a0c52a0ea1f07b3ea/src/main/java/cd/go/authorization/okta/Constants.java#L27-L28
Support for "1.0" will soon be removed in GoCD 23.2.0 as part of clean-up to support https://github.com/gocd/gocd/issues/11629 (functionality also likely of use to this plugin to increase security) Authorization extension API version 2.0 was introduced in GoCD 19.2.0 and was supposed to be removed many years ago, but was probably forgotten.
https://plugin-api.gocd.org/current/#deprecations-across-extensions58

Supports version 2 of Authorization extension API. Version 2 adds the following new messages:

Is Valid User
Get User Roles

Plugins Capabilities message is enhanced to add a new capability can_get_user_roles.
The authorization extension v1 has been deprecated. This version will be removed in a release scheduled for September 2019. Plugin developers should upgrade their plugins to the latest version.

Although these additional messages are supported on V2, they are only used/required if you want GoCD access token-based authentication to work for users via the plugin, or if the the plugin declares capability can_get_user_roles e.g add on to the below
https://github.com/szamfirov/gocd-okta-oauth-authorization-plugin/blob/c05e9a80027d5f481f34020a0c52a0ea1f07b3ea/src/main/java/cd/go/authorization/okta/models/Capabilities.java#L24-L33
Tl;DR - I believe you can likely just declare "2.0" API version compatibility and things will work just fine as the server will assume the plugin does not support user roles, and does not support GoCD access/API token usage. This will work on GoCD versions 19.2.0+ so going back 3.5 years or so.

Hello @chadlwilson , thank you for raising this and also for providing all the extra information and references.
I've just released version 2.0.0 for this plugin since it now points to the newer v2 authorization extension API. It's worth pointing out that it was done on a best effort basis - the builds and tests ran fine, however, I cannot test this in a running GoCD instance because I'm no longer actively using the product.
In terms of future maintenance, I'm more than happy to hand over the rains and transfer the ownership of this plugin to someone who will actively support this (perhaps in gocd-contrib) just to allow for better maintenance and avoid any delays in the future.

I have been running the forked version of this plugin against GoCD 23.3.0 and can attest that it works as expected, or at least good enough for me not to see any difference in operation.

Hi @szamfirov - I have invited you to the gocd-contrib org so you should have permissions to transfer the repository into the org. Let me know if its not given as an option and I've missed a permission.
This way all of the releases, issues, PRs etc come with it. If you'd rather not do it this way, I can fork the repo there, but a repo transfer is usually the cleanest, as GitHub puts URL redirects into place and such :-)
We can keep it alive there from a basic perspective, alongside other plugins.

Thanks for arranging this on such short notice, @chadlwilson. I just made an attempt to transfer the repo but I've hit an insufficient permissions error:

@szamfirov Sorry, fixed the permissions, can you please try again now?

There we go, transferred it 👍

@szamfirov awesome! I had to make you an org member temporarily to allow the transfer but have now reinvited you as a collaborator on the repository.
When I get a bit of time I'll probably make some tweaks to automate the releasing and dependency upgrades consistent with other plugin repos and cut a new patch release to validate the process.
Thanks for your efforts with this plugin 🙏

When I get a bit of time I'll probably make some tweaks to automate the releasing and dependency upgrades consistent with other plugin repos and cut a new patch release to validate the process.

Sounds like a good plan.

Thanks for your efforts with this plugin 🙏

No worries at all, it was my pleasure. And who knows.. I might come back to this at some point as well :)
Btw, thank you for the nice gesture with updating the copyright 🤗


docs(README): Properly indent a fenced code block

Did a trivial rebase that doesn't warrant another look.


SERP HTML Results by Task Id - Incorrect Function

As I was looking through the code to add the SERP: Google Reviews calls I notice that you have the incorrect function listed for the SERP: HTML Results by Task Id.
File DFSClient/Models/SERP_API/GetSerpHtmlResultsByTaskId.php
Line 9 appears as
protected $requestToFunction = 'srp_extra_tasks_get';
It should be
protected $requestToFunction = 'srp_html_tasks_get';

Yes, it will be fixed tomorrow.
Thank you.


WebGPU: Tests failing in tests/compute

The following tests are currently failing for wgpu.
This task is about triaging these issues -- either fix on the spot or file a more detailed task.

tests/compute/buffer-type-splitting.slang
tests/compute/cbuffer-legalize.slang
tests/compute/compile-time-loop.slang
tests/compute/constexpr.slang
tests/compute/discard-stmt.slang
tests/compute/func-param-legalize.slang
tests/compute/func-resource-param.slang
tests/compute/global-init.slang
tests/compute/interface-shader-param-in-struct.slang
tests/compute/interface-shader-param.slang
tests/compute/kernel-context-threading.slang
tests/compute/loop-unroll.slang
tests/compute/matrix-layout.hlsl.3
tests/compute/non-square-column-major.slang
tests/compute/non-square-row-major.slang
tests/compute/row-major.slang

https://github.com/shader-slang/slang/issues/5221#issuecomment-2393011535 (RWByteAddressBuffer emits array with no type field.)

Tests

buffer-type-splitting

https://github.com/shader-slang/slang/issues/5222 (WGPU error: Binding doesn't exist)

Tests

cbuffer-legalize

https://github.com/shader-slang/slang/issues/5226 (WGPU error: nested structures cannot be used for entry point IO)

Tests

compile-time-loop
constexpr
discard-stmt

https://github.com/shader-slang/slang/issues/5227 (WGPU error: sampler with "unfilterable-float" sample type used to filter)

Tests

func-param-legalize

https://github.com/shader-slang/slang/issues/5228 (WGPU error: runtime-sized array not in 'storage' address space)

Tests

func-resource-param

https://github.com/shader-slang/slang/issues/5229 (WGPU error: no address space declared for global variable)

Tests

global-init

https://github.com/shader-slang/slang/issues/4938 (Slang error: No type conformances are found for interface...)

Tests

interface-shader-param-in-struct
interface-shader-param

https://github.com/shader-slang/slang/issues/5222 (WGPU error: Number of entries (2) did not match the expected number of entries)

Tests

kernel-context-threading
matrix-layout(.hlsl)
non-square-column-major
non-square-row-major
row-major

https://github.com/shader-slang/slang/issues/4987 (WGSL error: array of runtime sized arrays)

Tests

loop-unroll


inDeck doesn't seem to have a license

I wasn't able to find a LICENSE file which means a lot is unknown for someone who might want to use or contribute to the codebase.
Proposed solution:
Use choosealicense.com to pick one for this project. My goto would be GPLv3 if you want to encourage contributions.

An oversight, thanks for pointing it out. Specified under quite permissive "unlicense".


Is a WASM client possible?

I've been trying to get demo_bevy to compile to WASM and work. In my JS console I get a terse error printed that points me to the UdpSocket::bind call in the client code. So I'm assuming this just isn't a thing in browser WASM land (no way to simply bind to the network interface... obvious in retrospect.)
I don't really know what my options are. WebSockets is TCP and probably not appropriate. I believe there's some hack to let you relay network data from JavaScript land to WASM land via javascript function calls.
Good advice also counts as resolution in my case. Thanks for the really cool crate!

I am also very much interested in a WASM compatible version.

Currently, there is no compatibility since the library uses UDP for networking.
There is some effort to use traits for the transport so it would be able to make a transport layer compatible with WASM.
But that won't happen so soon
Trait PR: https://github.com/lucaspoffo/renet/pull/36

Cool! I'll keep an eye on #36 and contribute somehow if I'm able to. Thanks!


Bug: payload validation is skipped when item is returned via ReturnValuesOnConditionCheckFailure

Expected Behaviour
When making a function idempotent via the @idempotent decorator and enabling payload validation the Idempotency utility should raise a payload validation exception when the payload in subsequent requests differs from the one stored.
With this configuration:
persistence_layer = DynamoDBPersistenceLayer(table_name=os.environ["TABLE_NAME"])
config = IdempotencyConfig(
    event_key_jmespath='["rcn", "subscriptionType"]',
    payload_validation_jmespath="customerAccounts",
)

we are using two fields from the payload to generate the idempotency hash (rcn and subscriptionType) but we are using a different key (customerAccounts) for payload validation.
If we send the following two requests:
{
  "rcn": "RCN-000-000-000-000",
  "customerAccounts": {
    "customerAccount": [
      {
        "accountId": "12345",
        "accountType": "someaccounttype"
      }
    ]
  },
  "subscriptionType": "somesubscriptiontype"
}

and
{
  "rcn": "RCN-000-000-000-000",
  "customerAccounts": {
    "customerAccount": [
      {
        "accountId": "54321",
        "accountType": "someaccounttype"
      }
    ]
  },
  "subscriptionType": "somesubscriptiontype"
}

These two requests should be considered idempotent because the compound value of rcn and subscriptionType is the same across requests.
At the same time, the values under customerAccounts have changed between requests (note customerAccounts.customerAccount[0].accountId being different). This means the payload validation should fail in the second request.
Current Behaviour
The function does not throw a validation error even though payload validation is enabled and parts of the payload differ from the stored one.
See screenshot below, where I send both requests and both are successful:

Code snippet
import os
from aws_lambda_powertools.utilities.idempotency import (
    DynamoDBPersistenceLayer,
    IdempotencyConfig,
    idempotent,
)
from aws_lambda_powertools.utilities.typing import LambdaContext

persistence_layer = DynamoDBPersistenceLayer(table_name=os.environ["TABLE_NAME"])
config = IdempotencyConfig(
    event_key_jmespath='["rcn", "subscriptionType"]',
    payload_validation_jmespath="customerAccounts",
)

@idempotent(persistence_store=persistence_layer, config=config)
def handler(event: dict, context: LambdaContext):
    return True

Possible Solution
As part of a feature added in #3446 we are using DynamoDB ReturnValuesOnConditionCheckFailure whenever available. This feature allows the DynamoDB to return an item that caused a conditional operation to fail, which in turn allows the Idempotency utility to get the IdempotencyRecord of a request without having to do an additional read.
In the base idempotency class (here), we have added an if/else statement that uses the returned item when available, or otherwise it calls the _get_idemptoency_record() method when one is not available - this last case can happen when customers are using older versions of boto3.
With the current implementation, the logic that validates the payload is executed only in the else clause, which causes payload validation to be skipped.
A potential fix would be to make the _validate_payload() method in the BasePersistenceLayer class and then call it on the exc.old_data_record, similar to this:
record = exc.old_data_record
if exc.old_data_record is not None:
  self.persistence_store.validate_payload(
    self.data,
    record
  )
  else:
    record = self._get_idempotency_record()

Steps to Reproduce
See steps above.
Powertools for AWS Lambda (Python) version
latest
AWS Lambda function runtime
3.12
Packaging format used
PyPi
Debugging logs
No response

I have tried implementing the fix I was suggesting in the OP but I wasn't able to make the tests pass :/

Thank you for opening this detailed issue Andrea! I'll try to finish the PR

couldn't find the test for this enhancement (that potentially triggered this regression) -- looking at the history now

found the test that was modified with this feature but seems to be working as expected, will look at E2E and create one if there isn't one to be absolutely sure.

okay managed to reproduce - validation at nested fields aren't working, that's why tests worked but @dreamorosi payload didn't. Docs also use a single key/value, compound would also work, but nested fields didn't.
NOTE. This is not related to ReturnValueOnConditionCheckFailure. Our tests caught the change before, and that's why @rubenfonseca wasn't able to validate.
I've created a functional test along w/ some basic tooling (we sorely need testing tooling) to make it easier to identify the root cause. I suspect it might be down to ordering as hashing it's occuring.
def test_idempotent_lambda_already_completed_with_validation_bad_nested_payload(
    persistence_store: DynamoDBPersistenceLayer,
    timestamp_future,
    lambda_context,
    request: FixtureRequest,
):
    # GIVEN an idempotency config with a compound idempotency key (refund, customer_id)
    # AND with payload validation key to prevent tampering

    validation_key = "details"
    idempotency_config = IdempotencyConfig(
        event_key_jmespath='["refund_id", "customer_id"]', payload_validation_jmespath=validation_key
    )

    # AND a previous transaction already processed in the persistent store
    transaction = {
        "refund_id": "ffd11882-d476-4598-bbf1-643f2be5addf",
        "customer_id": "9e9fc440-9e65-49b5-9e71-1382ea1b1658",
        "details": {"company_name": "Parker, Johnson and Rath", "currency": "Turkish Lira"},
    }

    stubber = stub.Stubber(persistence_store.client)
    ddb_response = build_idempotency_put_item_response_stub(
        data=transaction,
        expiration=timestamp_future,
        status="COMPLETED",
        request=request,
        validation_data=transaction[validation_key],
    )

    stubber.add_client_error("put_item", "ConditionalCheckFailedException", modeled_fields=ddb_response)
    stubber.activate()

    # AND an upcoming tampered transaction
    tampered_transaction = copy.deepcopy(transaction)
    tampered_transaction["details"]["currency"] = "Euro"

    @idempotent(config=idempotency_config, persistence_store=persistence_store)
    def lambda_handler(event, context):
        return event

    # WHEN the tampered request is made
    # THEN we should raise
    with pytest.raises(IdempotencyValidationError):
        lambda_handler(transaction, lambda_context)

    stubber.assert_no_pending_responses()
    stubber.deactivate()

Waiting for E2E to run with this new case (functional tests are passing) -- I can't for the love of me reproduce it. Added exact same nesting and change in functional and E2E test above in the PR -- I'll try one last time with a manual Lambda tomorrow.
https://github.com/aws-powertools/powertools-lambda-python/actions/runs/7976558714

I'll try one last time with a manual Lambda tomorrow.

No need.
I have deployed the manual stack from scratch & ran the two payloads again and the second request is throwing as expected.
Given this I can only assume that I must have made a mistake. Apologies for making you run in circles and wasting your time @rubenfonseca & @heitorlessa.
I'll be more thorough in the future.

not at all. First, better safe than sorry. Second, this was an useful exercise to improve our test coverage on payload validation as it was overly simplistic :)
If anything, keep it coming @dreamorosi. It was also useful exercise to discover the ordering issue in TS nevertheless.
In case I haven't said it this month... it's a pleasure working with you :)


Flatten out dependent contracts

We are going to pull in all of our contract dependencies and maintain them here

done


Restriction and the Right way of deleting functions from portal should be mentioned.

For the Linux Consumption function app, each functions deployed on Function App cannot be deleted from portal.
In the Portal, "Delete" button is diabled. Just diabling may confuse users. Right way of deleting functions (deleting code from project itself and deploying again may be the solution) should also be mentioned here.

Thank you very much in advance!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8b1ff97a-0ca7-c91b-5b45-370212407a51
Version Independent ID: b60719ca-3e64-8a00-75bb-dda1d8119b21
Content: Create a Python function from the command line - Azure Functions
Content Source: articles/azure-functions/create-first-function-cli-python.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

@yutaro113 Thank you for your suggestions . We will have this reviewed with the content team and update the thread.

@yutaro113 Thank you for your suggestions . We will have this reviewed with the content team and update the thread.

Hello @yutaro113,
Thank you for reaching out! I have conveyed your feedback to the portal team. As this issue does not warrant any documentation changes, I will now proceed to close this issue out.
Please tag me in your response if there are any additional concerns. Thank you!

Hello @yutaro113,
Thank you for reaching out! I have conveyed your feedback to the portal team. As this issue does not warrant any documentation changes, I will now proceed to close this issue out.
Please tag me in your response if there are any additional concerns. Thank you!


Fixing bug in filenames with dashes

Filenames with dashes would not create valid rust identifiers since they
cannot include dashes in the identifier.
Additionally added attribute to turn off unused code warnings and moved
the #[allow(non_upper_case_globals)] to a global attribute

Thanks for the PR. Yeah this solves the specific case for dash maybe there is a lib like lodash for rust which will remove all special characters like snakeCaseify or camelCaseify.

LGTM


KOGITO-9007 StateBasedNodeInstance not working with multiple instances including timers

Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[X] You have read the contributors guide
[X] Your code is properly formatted according to this configuration
[X] Pull Request title is properly formatted: KOGITO-XYZ Subject
[X] Pull Request title contains the target branch if not targeting main: [0.9.x] KOGITO-XYZ Subject
[X] Pull Request contains link to the JIRA issue
[X] Pull Request contains link to any dependent or related Pull Request
[X] Pull Request contains description of the issue
[X] Pull Request does not include fixes for issues other than the main ticket

How to replicate CI configuration locally?

Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.
build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

How to retest this PR or trigger a specific build:

for pull request checks
Please add comment: Jenkins retest this

for a specific pull request check
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] tests

for quarkus branch checks
Run checks against Quarkus current used branch
Please add comment: Jenkins run quarkus-branch

for a quarkus branch specific check
Run checks against Quarkus current used branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-branch

for quarkus main checks
Run checks against Quarkus main branch
Please add comment: Jenkins run quarkus-main

for a specific quarkus main check
Run checks against Quarkus main branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-main

for quarkus lts checks
Run checks against Quarkus lts branch
Please add comment: Jenkins run quarkus-lts

for a specific quarkus lts check
Run checks against Quarkus lts branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] quarkus-lts

for native checks
Run native checks
Please add comment: Jenkins run native

for a specific native check
Run native checks
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] native

for native lts checks
Run native checks against quarkus lts branch
Please add comment: Jenkins run native-lts

for a specific native lts check
Run native checks against quarkus lts branch
Please add comment: Jenkins (re)run [kogito-runtimes|kogito-apps|kogito-examples] native-lts

Full Kogito testing (with cloud images and operator BDD testing)
Please add comment: Jenkins run BDD
This check should be used only if a big change is done as it takes time to run, need resources and one full BDD tests check can be done at a time ...

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

(tests) - kogito-runtimes job #2364 was: FAILURE
Possible explanation: Pipeline failure or project build failure

Reproducer
export BUILD_MVN_OPTS_CURRENT=-T 1C -Dvalidate-formatting -Prun-code-coverage
build-chain build cross_pr -f 'https://raw.githubusercontent.com/kiegroup/kogito-pipelines/main/.ci/pull-request-config.yaml' -o 'bc' -p kiegroup/kogito-runtimes -u https://github.com/kiegroup/kogito-runtimes/pull/2949 --skipParallelCheckout
NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution

Please look here: https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/main/job/pullrequest/job/kogito-runtimes.tests.kogito-runtimes/2364/display/redirect
Test results:

PASSED: 3196
FAILED: 0

Those are the test failures: none
See console log:

Console Logs
[2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Persistence :: MongoDB ........ SUCCESS [ 43.650 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Persistence MongoDB - Parent ......... SUCCESS [  0.029 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Persistence MongoDB .................. SUCCESS [  2.654 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Persistence MongoDB - Deployment ..... SUCCESS [  0.881 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Persistence :: PostgreSQL ..... SUCCESS [ 29.686 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Persistence PostgreSQL - Parent ...... SUCCESS [  0.030 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Persistence PostgreSQL ............... SUCCESS [  2.366 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Persistence PostgreSQL - Deployment .. SUCCESS [  1.362 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Process SVG :: Common ......... SUCCESS [ 13.093 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Process SVG - Parent ................. SUCCESS [  0.048 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Process SVG .......................... SUCCESS [ 15.009 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Process SVG - Deployment ............. SUCCESS [  1.090 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Process Management :: Common .. SUCCESS [ 11.163 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Process Management - Parent .......... SUCCESS [  0.050 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Process Management ................... SUCCESS [ 15.150 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Process Management - Deployment ...... SUCCESS [  0.780 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Source Files :: Common ........ SUCCESS [  5.805 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Source Files - Parent ................ SUCCESS [  0.047 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Source Files ......................... SUCCESS [ 42.046 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Source Files - Deployment ............ SUCCESS [  7.801 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Knative :: Parent ............. SUCCESS [  0.028 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Knative :: Eventing ........... SUCCESS [ 10.873 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Knative - Parent ..................... SUCCESS [  0.057 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Knative Eventing - Parent ............ SUCCESS [  0.049 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Knative Eventing ..................... SUCCESS [  1.379 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Knative Eventing - Deployment ........ SUCCESS [ 15.780 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Knative Serving - Parent ............. SUCCESS [  0.035 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Knative Serving ...................... SUCCESS [ 55.741 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Knative Serving - Deployment ......... SUCCESS [  4.964 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Events :: Parent .............. SUCCESS [  0.043 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Decisions SUCCESS [ 17.831 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events Decisions - Parent ............ SUCCESS [  0.023 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events Decisions ..................... SUCCESS [  1.045 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events Decisions - Deployment ........ SUCCESS [  1.730 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Predictions SUCCESS [ 10.985 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events Predictions - Parent .......... SUCCESS [  0.026 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events Predictions ................... SUCCESS [  1.148 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events Predictions - Deployment ...... SUCCESS [  1.368 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Rules .. SUCCESS [  8.975 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events Rules - Parent ................ SUCCESS [  0.033 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Rules :: Quarkus SUCCESS [  0.883 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events Rules - Deployment ............ SUCCESS [  1.563 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Events :: MongoDB ............. SUCCESS [ 21.638 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events MongoDB - Parent .............. SUCCESS [  0.086 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events MongoDB ....................... SUCCESS [01:00 min][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Events MongoDB - Deployment .......... SUCCESS [  1.119 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Marshallers :: Parent ......... SUCCESS [  0.029 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Marshallers:: Avro ............ SUCCESS [  9.084 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Quarkus:: Marshallers :: Parent SUCCESS [  0.035 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Quarkus:: Marshallers:: Avro:: Parent SUCCESS [  0.023 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Quarkus:: Marshallers:: Avro .. SUCCESS [  0.488 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Quarkus:: Marshallers:: Avro:: Deployment SUCCESS [  1.045 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Camel :: Parent .... SUCCESS [  0.037 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Camel :: Runtimes .. SUCCESS [  7.583 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Camel :: Deployment  SUCCESS [ 15.369 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Camel :: Integration Tests SUCCESS [ 57.391 s][2023-04-24T11:57:13.548Z] [INFO] Kogito :: Add-Ons :: Explainability ................ SUCCESS [ 13.631 s][2023-04-24T11:57:13.548Z] [INFO] Kogito Add-On Explainability - Parent .............. SUCCESS [  0.069 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Explainability ....................... SUCCESS [  5.080 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Explainability - Deployment .......... SUCCESS [  1.053 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Explainability - Integration tests ... SUCCESS [ 35.956 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Jobs .......................... SUCCESS [  0.038 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Jobs :: API ................... FAILURE [  0.497 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Parent ................. SUCCESS [  0.034 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Common - Parent ........ SUCCESS [  0.047 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Common - Messaging ..... SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus - Rest Callback ............. SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Jobs :: Management Common ..... SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Management - Parent .... SUCCESS [  0.025 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs - Management ........... SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Management - Deployment  SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Messaging - Parent ..... SUCCESS [  0.021 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs - Messaging ............ SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Messaging - Deployment . SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Knative Eventing - Parent SUCCESS [  0.022 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs - Knative Eventing ..... SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito Add-Ons Quarkus Jobs Knative Eventing - Deployment SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: E-Mail :: Common .............. SUCCESS [  7.816 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Mail - Parent ........................ SUCCESS [  0.024 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Mail ................................. SUCCESS [ 43.241 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Mail - Deployment .................... SUCCESS [  0.990 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Monitoring .................... SUCCESS [  0.030 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Monitoring Core ............... SUCCESS [ 21.011 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Monitoring - Parent .................. SUCCESS [  0.026 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Monitoring Core ...................... SUCCESS [ 16.818 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Monitoring Prometheus Common .. SUCCESS [  0.527 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Monitoring Prometheus - Parent ....... SUCCESS [  0.030 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Monitoring Prometheus ................ SUCCESS [  4.379 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Monitoring Prometheus - Deployment ... SUCCESS [  1.443 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Monitoring Elastic Common ..... SUCCESS [  8.340 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Monitoring Elastic - Parent .......... SUCCESS [  0.022 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Monitoring Elastic ................... SUCCESS [  1.219 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Monitoring Elastic - Deployment ...... SUCCESS [  0.572 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Task Notification - Parent ........... SUCCESS [  0.023 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Task Notification .................... SUCCESS [  4.448 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Task Notification - Deployment ....... SUCCESS [  0.735 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Tracing ....................... SUCCESS [  0.030 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: TypedValue API ................ SUCCESS [  9.648 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Tracing :: API ................ SUCCESS [  8.062 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Tracing :: Common ............. SUCCESS [ 20.184 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Tracing Decision - Parent ............ SUCCESS [  0.061 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Tracing Decision ..................... SUCCESS [ 20.556 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Tracing Decision - Deployment ........ SUCCESS [  1.828 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Tracing Decision - Integration tests . SUCCESS [01:29 min][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Task Management :: Common ..... SUCCESS [  0.657 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Task Management - Parent ............. SUCCESS [  0.060 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Task Management ...................... SUCCESS [  5.166 s][2023-04-24T11:57:13.549Z] [INFO] Kogito Add-On Task Management - Deployment ......... SUCCESS [  0.618 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Integration Tests :: Quarkus ............. SUCCESS [  0.080 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Integration Tests :: Quarkus :: OpenAPI Client Codegen SUCCESS [01:57 min][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Integration Tests :: Quarkus :: Rules .... SUCCESS [ 54.189 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Integration Tests :: Quarkus :: Decisions  SUCCESS [01:02 min][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Integration Tests :: Quarkus :: RESTEasy Classic SUCCESS [ 45.978 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Integration Tests :: Quarkus :: RESTEasy Reactive SUCCESS [ 51.007 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Maven Plugin ............................. SUCCESS [  8.337 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Integration Tests :: Maven Plugin ........  SUCCESS [01:30 min][2023-04-24T11:57:13.549Z] [INFO] Kogito :: DB Scripts Collection .................... SUCCESS [  0.534 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Persistence :: RocksDB ........ SUCCESS [ 12.949 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Predictions ................... SUCCESS [  0.033 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Predictions :: API ............ SUCCESS [  6.471 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Predictions :: SMILE .......... SUCCESS [  8.178 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Serverless Workflow :: OpenAPI:: Parser .. SUCCESS [  5.128 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Serverless Workflow :: Executor .......... SUCCESS [  9.215 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot .............................. SUCCESS [  0.124 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot :: BOM ....................... SUCCESS [  0.228 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Spring Boot ................... SUCCESS [  0.062 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: CloudEvents :: Spring Boot .... SUCCESS [  0.028 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Messaging :: Spring Boot ...... SUCCESS [  0.919 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Spring Boot :: Events - Parent  SUCCESS [  0.026 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Decisions :: Spring Boot SUCCESS [  0.332 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Predictions :: Spring Boot SUCCESS [  0.506 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Rules :: Spring Boot SUCCESS [  0.264 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Events :: SprintBoot :: Process :: Kafka SUCCESS [  2.934 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Events ::  MongoDB :: SprintBoot SUCCESS [ 15.040 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot :: Starters Parent ........... SUCCESS [  9.001 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot :: Starter :: Decisions ...... SUCCESS [  0.294 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Messaging :: Spring Boot (ITs)  SUCCESS [ 57.284 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Spring Boot :: Monitoring :: Parent SUCCESS [  0.031 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Monitoring Core Springboot .... SUCCESS [ 15.302 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Monitoring Prometheus Springboot SUCCESS [  0.739 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Monitoring Elastic Springboot . SUCCESS [  0.495 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Explainability :: Spring Boot Addon SUCCESS [ 13.175 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot :: Starter :: Rules .......... SUCCESS [  0.361 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot :: Starter :: Processes ...... SUCCESS [  0.481 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot :: Starter :: Predictions .... SUCCESS [  0.137 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot :: Starter ................... SUCCESS [  0.138 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Jobs :: Management SprintBoot Addon SKIPPED[2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: E-Mail :: Spring Boot Addon ... SUCCESS [  0.788 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Task notification :: Spring Boot Addon SUCCESS [  2.294 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Tracing :: Spring Boot ........ SUCCESS [ 17.290 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Rest Exception Handler:: Spring Boot ..... SUCCESS [ 11.135 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Process SVG :: Spring Boot Addon SUCCESS [ 12.782 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Process Management :: Spring Boot Addon SUCCESS [ 11.312 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Task Management :: Spring Boot Addon SUCCESS [  0.654 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Spring Boot :: Kubernetes ..... SUCCESS [ 21.109 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Spring Boot :: Persistence :: Parent SUCCESS [  0.028 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Persistence File System :: Springboot SUCCESS [  0.280 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Persistence Infinispan :: Springboot SUCCESS [  1.397 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Persistence JDBC :: Springboot  SUCCESS [  0.729 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Persistence MongoDB :: Springboot SUCCESS [  1.608 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Add-Ons :: Persistence PostgreSQL :: Springboot SUCCESS [  1.022 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Spring Boot :: Maven Archetype ........... SUCCESS [03:05 min][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Test Utilities :: Spring Boot ............ SUCCESS [ 20.869 s][2023-04-24T11:57:13.549Z] [INFO] Kogito :: Integration Tests :: Spring Boot ......... SUCCESS [05:17 min][2023-04-24T11:57:13.549Z] [INFO] ------------------------------------------------------------------------[2023-04-24T11:57:13.549Z] [INFO] BUILD FAILURE[2023-04-24T11:57:13.549Z] [INFO] ------------------------------------------------------------------------[2023-04-24T11:57:13.549Z] [INFO] Total time:  16:49 min (Wall Clock)[2023-04-24T11:57:13.549Z] [INFO] Finished at: 2023-04-24T07:57:13-04:00[2023-04-24T11:57:13.550Z] [INFO] ------------------------------------------------------------------------[2023-04-24T11:57:13.550Z] [ERROR] Failed to execute goal net.revelc.code:impsort-maven-plugin:1.8.0:check (default) on project kogito-addons-jobs-api: Imports are not sorted in /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes/bc/kiegroup_kogito-runtimes/addons/common/jobs/api/src/test/java/org/kie/kogito/jobs/api/JobCallbackResourceDefTest.java -> [Help 1][2023-04-24T11:57:13.550Z] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal net.revelc.code:impsort-maven-plugin:1.8.0:check (default) on project kogito-addons-jobs-api: Imports are not sorted in /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes/bc/kiegroup_kogito-runtimes/addons/common/jobs/api/src/test/java/org/kie/kogito/jobs/api/JobCallbackResourceDefTest.java[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:375)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:351)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:171)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:163)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:210)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:195)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.FutureTask.run (FutureTask.java:264)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.FutureTask.run (FutureTask.java:264)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)[2023-04-24T11:57:13.550Z]     at java.lang.Thread.run (Thread.java:829)[2023-04-24T11:57:13.550Z] Caused by: org.apache.maven.plugin.MojoFailureException: Imports are not sorted in /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes/bc/kiegroup_kogito-runtimes/addons/common/jobs/api/src/test/java/org/kie/kogito/jobs/api/JobCallbackResourceDefTest.java[2023-04-24T11:57:13.550Z]     at net.revelc.code.impsort.maven.plugin.AbstractImpSortMojo.fail (AbstractImpSortMojo.java:364)[2023-04-24T11:57:13.550Z]     at net.revelc.code.impsort.maven.plugin.AbstractImpSortMojo.fail (AbstractImpSortMojo.java:360)[2023-04-24T11:57:13.550Z]     at net.revelc.code.impsort.maven.plugin.CheckMojo.processResult (CheckMojo.java:33)[2023-04-24T11:57:13.550Z]     at net.revelc.code.impsort.maven.plugin.AbstractImpSortMojo.lambda$execute$3 (AbstractImpSortMojo.java:294)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:195)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:195)[2023-04-24T11:57:13.550Z]     at java.util.stream.ForEachOps$ForEachOp$OfRef.accept (ForEachOps.java:183)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:195)[2023-04-24T11:57:13.550Z]     at java.util.Spliterators$ArraySpliterator.forEachRemaining (Spliterators.java:948)[2023-04-24T11:57:13.550Z]     at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:484)[2023-04-24T11:57:13.550Z]     at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:474)[2023-04-24T11:57:13.550Z]     at java.util.stream.ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:150)[2023-04-24T11:57:13.550Z]     at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential (ForEachOps.java:173)[2023-04-24T11:57:13.550Z]     at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:234)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReferencePipeline.forEach (ReferencePipeline.java:497)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReferencePipeline$7$1.accept (ReferencePipeline.java:274)[2023-04-24T11:57:13.550Z]     at java.util.Spliterators$ArraySpliterator.forEachRemaining (Spliterators.java:948)[2023-04-24T11:57:13.550Z]     at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:484)[2023-04-24T11:57:13.550Z]     at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:474)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReduceOps$ReduceTask.doLeaf (ReduceOps.java:952)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReduceOps$ReduceTask.doLeaf (ReduceOps.java:926)[2023-04-24T11:57:13.550Z]     at java.util.stream.AbstractTask.compute (AbstractTask.java:327)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.CountedCompleter.exec (CountedCompleter.java:746)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:290)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.ForkJoinTask.doInvoke (ForkJoinTask.java:408)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.ForkJoinTask.invoke (ForkJoinTask.java:736)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReduceOps$ReduceOp.evaluateParallel (ReduceOps.java:919)[2023-04-24T11:57:13.550Z]     at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:233)[2023-04-24T11:57:13.550Z]     at java.util.stream.ReferencePipeline.reduce (ReferencePipeline.java:558)[2023-04-24T11:57:13.550Z]     at net.revelc.code.impsort.maven.plugin.AbstractImpSortMojo.execute (AbstractImpSortMojo.java:316)[2023-04-24T11:57:13.550Z]     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:370)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:351)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:171)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:163)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:210)[2023-04-24T11:57:13.550Z]     at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:195)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.FutureTask.run (FutureTask.java:264)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.FutureTask.run (FutureTask.java:264)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)[2023-04-24T11:57:13.550Z]     at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)[2023-04-24T11:57:13.550Z]     at java.lang.Thread.run (Thread.java:829)[2023-04-24T11:57:13.550Z] [ERROR] [2023-04-24T11:57:13.550Z] [ERROR] Re-run Maven using the -X switch to enable full debug logging.[2023-04-24T11:57:13.550Z] [ERROR] [2023-04-24T11:57:13.550Z] [ERROR] For more information about the errors and possible solutions, please read the following articles:[2023-04-24T11:57:13.550Z] [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException[2023-04-24T11:57:13.550Z] [ERROR] [2023-04-24T11:57:13.550Z] [ERROR] After correcting the problems, you can resume the build with the command[2023-04-24T11:57:13.550Z] [ERROR]   mvn  -rf :kogito-addons-jobs-api[2023-04-24T11:57:15.567Z] [ERROR] Error executing command mvn clean install  -s /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes@tmp/config3428726417278940771tmp -Dmaven.wagon.http.ssl.insecure=true -Dmaven.test.failure.ignore=true -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3 -T 1C -Dvalidate-formatting -Prun-code-coverage dependency:tree  -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -B. The process '/opt/tools/apache-maven-3.8.7/bin/mvn' failed with exit code 1[2023-04-24T11:57:15.567Z] [command]/usr/bin/docker system prune -f[2023-04-24T11:57:15.567Z] Total reclaimed space: 0B[2023-04-24T11:57:15.567Z] [INFO] Execution summary for kiegroup/kogito-runtimes[2023-04-24T11:57:15.567Z] # [BEFORE] [kiegroup/kogito-runtimes] export INTEGRATION_BRANCH=[2023-04-24T11:57:15.567Z] [INFO] OK [Executed in 0.579436 ms][2023-04-24T11:57:15.567Z]  [2023-04-24T11:57:15.567Z] # [BEFORE] [kiegroup/kogito-runtimes] bash -c "if [ ! -z '' ] && [ -f .ci/environments/update.sh ]; then .ci/environments/update.sh ""; fi"[2023-04-24T11:57:15.567Z] [INFO] OK [Executed in 4.789572 ms][2023-04-24T11:57:15.567Z]  [2023-04-24T11:57:15.567Z] # [COMMANDS] [kiegroup/kogito-runtimes] export MVN_CMD=`bash -c "if [ '' = 'true' ]; then printf 'deploy  '; else printf 'install'; fi"`[2023-04-24T11:57:15.567Z] [INFO] OK [Executed in 4.498787 ms][2023-04-24T11:57:15.567Z]  [2023-04-24T11:57:15.567Z] # [COMMANDS] [kiegroup/kogito-runtimes] mvn clean install  -s /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes@tmp/config3428726417278940771tmp -Dmaven.wagon.http.ssl.insecure=true -Dmaven.test.failure.ignore=true -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3 -T 1C -Dvalidate-formatting -Prun-code-coverage dependency:tree  -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -B[2023-04-24T11:57:15.567Z] [INFO] NOT OK [Executed in 1011763.175524 ms][2023-04-24T11:57:15.567Z] [ERROR] The process '/opt/tools/apache-maven-3.8.7/bin/mvn' failed with exit code 1[2023-04-24T11:57:15.567Z]  [2023-04-24T11:57:15.567Z] # [AFTER] [kiegroup/kogito-runtimes] docker system prune -f[2023-04-24T11:57:15.567Z] [INFO] OK [Executed in 167.135644 ms][2023-04-24T11:57:15.567Z]  [2023-04-24T11:57:15.567Z]  [2023-04-24T11:57:15.567Z] # Uploading artifacts[2023-04-24T11:57:15.567Z] [INFO] Will not upload any artifacts in CLI environment[2023-04-24T11:57:15.567Z]  [2023-04-24T11:57:15.567Z] [ERROR] Failed to execute commands for kiegroup/kogito-runtimes[2023-04-24T11:57:15.567Z] [ERROR] Failed to execute mvn clean install  -s /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes@tmp/config3428726417278940771tmp -Dmaven.wagon.http.ssl.insecure=true -Dmaven.test.failure.ignore=true -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3 -T 1C -Dvalidate-formatting -Prun-code-coverage dependency:tree  -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -B :[2023-04-24T11:57:15.567Z] [ERROR] The process '/opt/tools/apache-maven-3.8.7/bin/mvn' failed with exit code 1[Pipeline] }[Pipeline] // withCredentials[Pipeline] }[2023-04-24T11:57:15.859Z] Deleting 1 temporary files[Pipeline] // configFileProvider[Pipeline] }[Pipeline] // scriptPost stage[Pipeline] junit[2023-04-24T11:57:16.261Z] Recording test results[2023-04-24T11:57:21.271Z] [Checks API] No suitable checks publisher found.[Pipeline] archiveArtifacts[2023-04-24T11:57:21.360Z] Archiving artifacts[Pipeline] script[Pipeline] {[Pipeline] sh[2023-04-24T11:57:22.644Z] + rm -rf console.log[Pipeline] sh[2023-04-24T11:57:23.046Z] + wget --no-check-certificate -qO - https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/main/job/pullrequest/job/kogito-runtimes.tests.kogito-runtimes/2364/consoleText[2023-04-24T11:57:23.046Z] + tail -n 300


Use caching in CI

Codecov Report
Base: 91.67% // Head: 91.67% // No change to project coverage :thumbsup:

Coverage data is based on head (3f2d755) compared to base (5b3dbe4).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #272   +/-   ##
=======================================
  Coverage   91.67%   91.67%
=======================================
  Files         116      116
  Lines       17601    17601
=======================================
  Hits        16135    16135
  Misses       1466     1466

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add a global Minimum self delegation

Summary
Add a global minimum self delegation parameter, similar to the minimum commission rate.
Problem Definition
This isn't a big restriction, as limited validator slots already effectively has this requirement. However this increases the costs to spam the number of validators. The number of validators active in the last $UNBONDING_PERIOD can have unfortunate impacts on efficiency when an app-chain's module has other amplification factors on the load caused by validators.
The base SDK has some amplification factor here, (state storage, historical signing info windows), but on brief skim nothing concerning, hence why it likely wasn't thought about before.
Proposal
Add a global minimum self delegation parameter to the codebase. For Osmosis, I suggest making it something like 100 osmo, which makes attacks that concern me very infeasible.

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

If such a change is only enforced on MsgCreateValidator and MsgEditValidator, then we won't run into any issues with existing validators either.

@ValarDragon Which file would this global minimum need to be declared in? I see that each MsgCreateValidator and MsgEditValidator have MinSelfDelegation fields, but I'm assuming this issue is trying to set a global minimum that these have to conform with.

Register migration https://github.com/osmosis-labs/cosmos-sdk/blob/v0.45.0x-osmo-v7/x/staking/module.go#L143
Code for past migration logic: https://github.com/cosmos/cosmos-sdk/blob/master/x/staking/migrations/v046/store.go


ci: adds -skip flag to the race tests

This at least works now modulo the flakiness we already are aware of #992


docs: truffle how to tutorial

Hey @menezesphill I am going through the write up and ran into a snag.  I am getting this error while trying to list all XDC addresses bound to the mnemonic on truffle (the truffle console is not opening)
`
C:\Users\WalterBlueu\Pizza>truffle console --network xinfin
Error: Unknown arguments format passed to new HDWalletProvider. Please ensure you passed provider information along with either a mnemonic or private keys.
at getOptions (C:\Users\WalterBlueu\Pizza\node_modules@truffle\hdwallet-provider\src\constructor\getOptions.ts:144:11)
at new HDWalletProvider (C:\Users\WalterBlueu\Pizza\node_modules@truffle\hdwallet-provider\src\index.ts:74:19)
at Object.provider (C:\Users\WalterBlueu\Pizza\truffle-config.js:10:23)
at Object.getProvider (C:\Users\WalterBlueu\AppData\Roaming\npm\node_modules\truffle\build\webpack:\packages\provider\index.js:20:1)
at Object.create (C:\Users\WalterBlueu\AppData\Roaming\npm\node_modules\truffle\build\webpack:\packages\provider\index.js:13:1)
at TruffleConfig.get [as provider] (C:\Users\WalterBlueu\AppData\Roaming\npm\node_modules\truffle\build\webpack:\packages\config\dist\configDefaults.js:275:1)
at Object.detect (C:\Users\WalterBlueu\AppData\Roaming\npm\node_modules\truffle\build\webpack:\packages\environment\environment.js:19:1)
at Object.module.exports [as run] (C:\Users\WalterBlueu\AppData\Roaming\npm\node_modules\truffle\build\webpack:\packages\core\lib\commands\console\run.js:29:1)
at runCommand (C:\Users\WalterBlueu\AppData\Roaming\npm\node_modules\truffle\build\webpack:\packages\core\lib\command-utils.js:201:1)
Truffle v5.5.30 (core: 5.5.30)
Node v16.17.0
C:\Users\WalterBlueu\Pizza>
`

Hey @menezesphill I am going through the write up and ran into a snag. I am getting this error while trying to list all XDC addresses bound to the mnemonic on truffle (the truffle console is not opening)

Ho there @WalterBlueu, there is a typo in the .env file, it reads:
mnemonoic

instead of
mnemonic

@menezesphill this is great, I have accepted the pull request and am going to close out the bounty and pay you

@menezesphill I am sending payment out now: $1,000 at $0.02643/XDC = 37836 XDC

Thank you, @WalterBlueu, my pleasure to help. Let me know if you want me to work on a different bounty (hardhat or REMIX). I didn't apply for those because I wanted to leave room for other bounty hunters.

@menezesphill we will be launching more bounties later today, please do check them out


[NT AUTHORITY\NETWORK SERVICE]  in tenant database

I was getting an error that [NT AUTHORITY\NETWORK SERVICE] user does not exist in the server when I use Export-NAVApplication inside a container. I'm using the databases created by navcontainerhelper.
Looking at the database with SQL Management Studio I can see that the [NT AUTHORITY\NETWORK SERVICE] user is created in tenant/default database but not in CRONUS. And it in fact not one the server users.
At the same time [NT AUTHORITY\SYSTEM] exists in all databases.
If I add the NetworkService to the users before exporting the application, then there is no problem.
Is that the intended behavior?
(onprem:14.5.35970.0-w1 + nch <IP_ADDRESS>

Could you submit a repro script?
Hent Outlook til iOShttps://aka.ms/o0ukef

Fra: Erik P. Ernst<EMAIL_ADDRESS>Sendt: Tuesday, January 14, 2020 4:35:48 PM
Til: microsoft/navcontainerhelper<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Emne: [microsoft/navcontainerhelper] [NT AUTHORITY\NETWORK SERVICE] in tenant database (#818)
I was getting an error that [NT AUTHORITY\NETWORK SERVICE] user does not exist in the server when I use Export-NAVApplication inside a container. I'm using the databases created by navcontainerhelper.
Looking at the database with SQL Management Studio I can see that the [NT AUTHORITY\NETWORK SERVICE] user is created in tenant/default database but not in CRONUS. And it in fact not one the server users.
At the same time [NT AUTHORITY\SYSTEM] exists in all databases.
If I add the NetworkService to the users before exporting the application, then there is no problem.
Is that the intended behavior?
(onprem:14.5.35970.0-w1 + nch <IP_ADDRESS>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fnavcontainerhelper%2Fissues%2F818%3Femail_source%3Dnotifications%26email_token%3DACSGUA6LVH6GXVIMYPU37ALQ5XLVJA5CNFSM4KGVBQAKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IGC6FNQ&data=02|01|freddy.kristiansen%40microsoft.com|67c5244b321b4b6cde2408d799076e01|72f988bf86f141af91ab2d7cd011db47|1|0|637146129497923442&sdata=GuJygyJuoJ4k%2FQAdko6rMrfNu%2Fw5pp1NzX9CNico%2FwA%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACSGUA7JRX4532VOU3Q77D3Q5XLVJANCNFSM4KGVBQAA&data=02|01|freddy.kristiansen%40microsoft.com|67c5244b321b4b6cde2408d799076e01|72f988bf86f141af91ab2d7cd011db47|1|0|637146129497923442&sdata=%2F%2F7bseMcgkzzbPOPWwgtdMzl5A%2B2nFJ1JDWyexjEhNE%3D&reserved=0.


Set fixed hostname and make it persistent

For elemental /etc/hostname -> /usr/local/etc/hostname, this file has to be updated
to make change persistent.
Fixes https://github.com/rancher/elemental/issues/221
Signed-off-by: Michal Jura<EMAIL_ADDRESS>

Codecov Report

Merging #106 (8bcfb18) into main (f243498) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #106   +/-   ##
=======================================
  Coverage   29.16%   29.16%
=======================================
  Files           5        5
  Lines         360      360
=======================================
  Hits          105      105
  Misses        251      251
  Partials        4        4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f243498...8bcfb18. Read the comment docs.

rebased


这是个伪开源项目, 公司网站也打不开了

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

哪个网站打不开？

https://xverse.cn/zh-cn, 看了下 现在可以了


Time-varying vaccine efficacy parameters

This functionality would help to support time-varying mixtures of vaccine-types when approimating multiple vaccines.
These should be fairly simple to implement with the interpolation in odin and tt_ options similar to other time-varying inputs.

fixed in #42


[WSL] switch should require a terminal at the end of each case, with a 'fallthrough' keyword when needed

Migrated from https://bugs.webkit.org/show_bug.cgi?id=186775:
At 2018-06-18T16:22:07Z<EMAIL_ADDRESS>wrote:
As per our discussion with Phil.
Our definition of switch is already sufficiently far from C (for example we don't support Duff's device) that adding this requirement should be reasonable.

At 2018-08-31T20:01:16Z<EMAIL_ADDRESS>wrote:
*** Bug 188879 has been marked as a duplicate of this bug. ***


added geeky quote

Ineligible Repository
Your PR was submitted to a repository that is not participating in Hacktoberfest. Maintainers of the repository can add the "hacktoberfest" topic to their repository if they wish to participate. Alternatively, an individual PR can be opted-in with a maintainer adding the "hacktoberfest-accepted" label to the PR.
Can you guys help me with this please?


Setting sandbox attribute of frame

Is there some way to set the sandbox attribute of the iframe? Specifically, I want to prevent the child inside the iframe from being able to inject javascript inside the context of the parent.

Hi @th174.
You can do:
const MyComponent = zoid.create({
    attributes: {
        iframe: {
            sandbox: '...'
        }
    }
})

That said:

I want to prevent the child inside the iframe from being able to inject javascript inside the context of the parent

If the iframe is on a different domain, that will be impossible anyway, even without sandbox

If the iframe is on a different domain, that will be impossible anyway, even without sandbox

That's currently how it is, however, because of some unrelated requirements, I might need to reverse proxy the iframe's domain through the parent's domain. In that case, I would need the sandbox to preserve the same separation separation of permissions.

Interesting. Could you reverse-proxy onto a subdomain? Otherwise the site will also have same-domain access to any of your server's urls/apis.

I was hoping to prevent that by revoking allow-same-origin access with the sandbox attribute. Would that not be sufficient?

That would work, but what if somebody redirects to the page outside of an iframe? Using a subdomain would give an extra layer of security for cases like that.

After removing the allow-same-origin access, I'm getting the following errors:

Uncaught Error: Unexpected init message from domain null -- expected message from http://localhost:8080


Move most of ResourcesRestOperations to generated

Resolves https://github.com/Azure/autorest.csharp/issues/3094

API change check
API changes are not detected in this pull request.


Allow switching to verbose mode without having to kill the flutter tool

It would be nice if verbose logging can be turned on via a keyboard shortcut:
r - hot reload
R - hot restart
v - enable/disable verbose logging
This is a minor FR. Motivation is to support users who either forget to pass the -v flag or use flutter tooling in build/run subsystems that wrap flutter tools where it might not be trivial to pass options through.

I think the best way to do this would be to allow the logger verbosity to be configured within the class itself. this could be done via a custom implementation of the Logger class.


#71 - saving planting

Current coverage is 32.30%

Merging #72 into master will decrease coverage by -2.12% as of 6b5b4a9

@@            master    #72   diff @@
=====================================
  Files            6      6
  Stmts           61     65     +4
  Branches         0      0
  Methods          0      0
=====================================
  Hit             21     21
  Partial          0      0
- Missed          40     44     +4

Review entire Coverage Diff as of 6b5b4a9

Powered by Codecov. Updated on successful CI builds.


needs documentation without the commentary

The canonical link for documentation ( https://muut.com/riotjs/docs/ ) reads as more of a rant about the state of current client-side application design and manifesto about good design. While I agree with the sentiments expressed, I feel that the commentary actively gets in the way of using the this documentation as either a learning tool or as reference material. Have you considered breaking out the reference material to a separate page?

Riot 2.0 comes along with a new API documentation:
https://muut.com/riotjs/api/
Hope you like it!
Closing this one.


Implement test fixtures to test multiple types of data inputs and calendars

Description
xarray has a fancy mechanism to test multiple calendards without multiplying the number of tests. It uses pytest fixtures. I think we should look into it and mimic their approach to avoir having to type boilerplate code for our test framework.

@Zeitsperre Could you add to testdata sample files for calendars 360, no_leap (365) and standard for variables: tas, tasmin, tasmax, pr, prsn ? One or two year of daily data for a couple of grid points.

Can do. Expect some new data by Thursday. Suggestions welcome.

There is some there already:
https://github.com/Ouranosinc/xclim/tree/master/tests/testdata
one year only

I know, but there are no model datasets with a standard calendar.

I thought we could use NRCAN.... not sure if I uploaded a leap year

Non, c'est 1990
On Tue, Oct 30, 2018 at 1:37 PM Travis Logan<EMAIL_ADDRESS>wrote:

I thought we could use NRCAN.... not sure if I uploaded a leap year
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Ouranosinc/xclim/issues/52#issuecomment-434396858,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AP4kHHgJUvFb1-6lujRoBqV43ok0tgCWks5uqI5ngaJpZM4XGOpS
.

--
Sébastien Biner


Adaptation to shadow DOM v1.

According to Starcounter/RebelsLounge#76

@tomalec could You please take a look on this?

Ping @tomalec

Ok, new version is 2.1.0


Wrap pg_dump's ability to dump only a few tables

Hi,
Conversely to the ability to exclude tables from the dump, which gonymizer already wraps, pg_dump also has the ability to specify exactly which tables should be exported:
  -t, --table=TABLE            dump the named table(s) only

This would be nice at the prototyping phase with gonymizer: just focus on a few tables, don't wait too much on the network.
Cheers

Workaround for users in the meantime:

use --log-level=DEBUG for a first run with gonymizer dump;
keep a record of the pg_dump command line with all the options, and feel free to stop the container;
update your script to use this pg_dump command instead of the usual gonymizer dump, and add the --table options as needed.

This can be done by using the same flags as pg_dump. You will need to "exclude" instead of "include:
--exclude-table=table

See: https://www.postgresql.org/docs/11/app-pgdump.html

Ended up using a different solution.


Accept brokerId while deletion of will

Will delete all the wills with the passed brokerId

Need to bump the version of aedes-persistence on aedes-cached persistence


Iterator.current throws null errors instead of StateError

If you call Iterator.current on an non-nullable iterator that's not in a valid location, it will throw a null-safety error rather than the StateError I would expect. This leads to a confusing debugging experience, since as a user I expect the Dart core libraries to be fully null-safe.
For example:
void main() {
  var iterator = <int>[].iterator..moveNext();
  print(iterator.current);
}

The iterator.current implementation deliberately tries to not add extra overhead for when the type variable is nullable.
That's why it does something as simple as _current ?? null as dynamic instead of trying to deduce whether T is nullable and then throw a special error if it's not.
The as dynamic is there instead of as T to allow dart2js to omit the downcast. That's one thing that we can't do with an explicit check for is T in order to throw a StateError.
That's not saying we couldn't do something different (we might risk changing the behavior of dart2js's unsound optimization modes, and probably increase their overhead).
The smallest thing which can throw a StateError would be something like:
T get current {
  var current = _current;
  if (current != null) return current;
  if (current is T) return current;   // Changes `as dynamic` + implicit downcast to `is` check
  throw StateError("No value in iterator");
}

It's not bad, approximately the same number of tests, but less unsafely optimizable for dart2js.

Doesn't dart2js have an optimization flag that allows it to omit all code paths that are guaranteed to throw subtypes of Error?

@nex3 No, dart2js at -O3 omits covariant and dynamic arguments type checks, and at -O4 omits null operand checks on arithmetic (very Dart 1 - they are impossible with sound null safety) and array bounds checks. as checks are currently never omitted, but can be omitted with a @pragma. There has never been an option to omit a throw expression written by the developer.

The --help documentation for -O3 say that it "Enables optimizations that respect the language semantics only on programs that don't ever throw any subtype of Error." Wouldn't that give you the freedom to optimize out user-authored (or in this case, core-library-authored) code paths that throw errors? I assumed that that's what it did do, and I'm disappointed to hear that it doesn't—it's valuable for authors at every level of the stack to be able to write code that reliably throws useful diagnostic errors in development, but doesn't add code size or runtime overhead at runtime.

To clarify, the language in the command line help was written that way to give users a simple guidance without being overly specific. We didn't want to list every kind of error that is currently optimized away, since the list is likely to change over time.
The guidance goal is to help users recognize what ensures that the semantics will not change at this level of optimization (e.g. if you have solid test coverage showing that you never see Error, you can be assured that -O3 will be safe.), but not to promise what the compiler may do with it.
It sounds to me, though, that you want a mechanism to ensure code is always tree-shaken and used only for development. We need to provide better guidance on that. We have also discussed adding mechanisms to annotate code with markers like @debugOnly that can later be leveraged to statically check/warn if code is used in a way that is not guaranteed to be tree-shaken.

assert is the supported mechanism for excluding code in production.
It does not have to throw an AssertionError, you can jump in front of that by throwing in the 'message' part:
assert(0 <= n && n < this.length, throw RangeError.index(n, this));

But assert doesn't interact well with the type system, especially in a world of null checks. For example:
int assertNonNull(int? value) {
  assert(value != null, throw ArgumentError("$value must not be null"));
  return value;
}

produces a static error on return value. (That said, @lrhn, an assertion that throws a StateError would certainly be preferable to the status quo.)

I have two broad points with respect to the dart2js message:

The current --help message is misleading. Whatever the original intent, it's very easy to read it as saying "you can throw Errors and have them optimized out in -O3 mode."

The behavior that -O3 seems to describe is highly desirable. Wrapping every check in assert()s is not only awkward and at odds with the type system, it's not the common design pattern when writing Dart code. Existing code by and large throws Error subclasses, especially at library boundaries where intelligible error messages are likely to be important during development.
The other side of that coin, though, is that if you did implement the semantics I'm describing (maybe as part of the more-aggressive -O4 level), you would automatically get a considerable code size reduction for free across every app. What's more, you'd do so while still working within the guarantees that the optimization levels have always provided: as long as app code is thoroughly tested and never throws an Error at runtime, it will continue to work great in production. If it would help, I can file a separate feature request for this.

I propose making moveNext() and .current return E?. .current will just hold the last execution value of moveNext(), which will be null if moveNext() was never called or has gone passed the end of the iteration.
What do you think?

We deliberately made current return E instead of E? when we introduced null safety, because the alternative is that each step of the iteration must do an extra null check, exactly the steps where we actually know that the value won't be null.
So returning E? is exactly what we didn't want.
That choice was also why we could no longer return null in the out-of-bounds accesses to current, but you were never supposed to call current in those positions, because you should know whether the last call to moveNext() returned true (or was ever called).
The official answer is still: Don't read current unless moveNext has just returned true.
if you do, the result is unspecified in the general case (it's an Iterable), and each specific iterable may choose to return a value or not.

Ok thanks for the clarification. I think the error would be more helpful if it threw an exception.


feat: add destroy and create options for generate physical name

Some resources are not directly replaceable when properties change. The internal generatePhysicalNameV2 function now adds destroyCreate to cause the resource to change that forces a destroy and create instead of a replacement.
Fixes #734

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

Very smart and interesting implementation. For reference there is something similar done for an API GW Deployment. This means that we should update constructs like KnowledgeBase who have a similar problem?

Very smart and interesting implementation. For reference there is something similar done for an API GW Deployment. This means that we should update constructs like KnowledgeBase that have a similar problem?

Yes, I think we should propagate this fix to the different places in, at least, the bedrock construct as this is not the only place where this issue is present


Adds f1 test statistic.

Implements https://github.com/wiki-ai/revscoring/issues/249

Current coverage is 89.00%

Merging #250 into master will increase coverage by +0.06% as of 599861b

@@            master   #250   diff @@
=====================================
  Files          187    189     +2
  Stmts         5932   5976    +44
  Branches         0      0
  Methods          0      0
=====================================
+ Hit           5276   5319    +43
  Partial          0      0
- Missed         656    657     +1

Review entire Coverage Diff as of 599861b

Powered by Codecov. Updated on successful CI builds.


Added zifencei, Bit Manipulation and privilege tests for RV32E

Description

This PR contains zifencei, bit manipulation and privilege arch-tests generated by riscv-ctg for RV32E.

Related Issues

#341

Ratified/Unratified Extensions

[ ] Ratified
[x] Unratified

List Extensions

RV32E_Zicsr, RV32E_Zifencei, RV32E_Zba, RV32E_Zbb, RV32E_Zbkb, RV32E_Zkn, RV32E_Zks, RV32E_Zbkc, RV32E_Zbs

Reference Model Used

[x] SAIL
[ ] Spike
[ ] Other - < SPECIFY HERE >

Mandatory Checklist:

[x] All tests are compliant with the test-format spec present in this repo ?
[x] Ran the new tests on RISCOF with SAIL/Spike as reference model successfully ?
[x] Ran the new tests on RISCOF in coverage mode
[x] Link to Google-Drive folder containing the new coverage reports (See this for more info): < https://drive.google.com/drive/folders/1SvsSVMX1PI9inIV9eEhQuh_tcjm7AJB7?usp=sharing >
[ ] Link to PR in RISCV-ISAC from which the reports were generated : < NA >
[x] Changelog entry created with a minor patch

Optional Checklist:

[x] RISCV-V CTG PR link if tests were generated using it : https://github.com/riscv-software-src/riscv-ctg/pull/74
[x] Were the tests hand-written/modified ? Zifencei tests were hand-written
[ ] Have you run these on any hard DUT model ? Please specify name and provide link if possible in the description
[ ] If you have modified arch_test.h Please provide a detailed description of the changes in the Description section above.

This is good to go


nbconvert can sometimes not be found, we should install it next to the extension like ipykernel

Some implications

For every python environment (different python versions), we'd end up installing nbconvert.
nbconvert is similar to jupyter, & its agnostic of the kernel & unrelated. Its basically a tool that can be used for all notebooks & all kernels. Hence I don't think we sholuld install this every time.

I still think we should install this into one place, the jupyter interpreter (single place for all tools that will work across all notebooks/kernels & python versions).
IpyKernel is slightly different.  This must be installed in each kernel, where as with nbconvert, its not a must.

nbconvert can sometimes not be found

Do we know when this cannot be found, i think we shoudl try to get to the bottom of that.

User didn't install full jupyter is the most obvious scenario.

User didn't install full jupyter is the most obvious scenario.

Can't we solve this by then checking if jupyter is also installed when checking for nbconvert?

You can have jupyter without nbconvert.

Yes. WHat i'm suggesting is when users install nbconvert, we also install jupyter into this single interpreter which is the jupyter interepreter.
I.e. a way to solve User didn't install full jupyter is the most obvious scenario.

Oh wait I see a problem, which maybe what you're trying to hightlight.
Raw kernel users won't have a designated jupyter interpreter. Hence when users attempt to use nbconvert, then this doesn't necessarily get installed into a single location, like we do with Jupyter.
Wouldn't using a single interpreter for such tools solve the problem. I.e. use a single python intererpetrt (we call this jupyter interpreter), for all tools like nbconvert, jupyter, etc.


Underscore in filenames in included graphics

I didn't manage to simplify my code enough to generate a MWE because I don't understand when tikzplotlib decides to include the figure as external graphics. tikzplotlib 0.9.9 generated a file containing the following line
\addplot graphics [includegraphics cmd=\pgfimage,xmin=0, xmax=20, ymin=0, ymax=20] {MRI_quality_xy-000.png}

This won't compile because the underscores are not properly escaped. The correct one is
\addplot graphics [includegraphics cmd=\pgfimage,xmin=0, xmax=20, ymin=0, ymax=20] {MRI\_quality\_xy-000.png}

EDIT: I should have said: the latter compile (the former throws an error), but it doesn't seem to find the image. So, neither seems correct.

An easy way to solve it would be to rename your image...
Just one question: Are your images saved in a subfolder, e.g., images? Then this path would also need to be given here. E.g.:
{images/MRI_quality_xy-00.png}.
(The option tex_relative_path_to_data allows to give a path which is automatically included. Unfortunately, for Windows the dashes are '' and therefore the option is not working and you need to do this manually. See #509 that I just created.

An easy way to solve it would be to rename your image...
Just one question: Are your images saved in a subfolder, e.g., images? Then this path would also need to be given here. E.g.:
{images/MRI_quality_xy-00.png}.
(The option tex_relative_path_to_data allows to give a path which is automatically included. Unfortunately, for Windows the dashes are '' and therefore the option is not working and you need to do this manually. See #509 that I just created.)

An easy way to solve it would be to rename your image...

That's what I did. But it is not a solution, it is a workaround.

Just one question: Are your images saved in a subfolder, e.g., images? Then this path would also need to be given here, e.g.,
{images/MRI_quality_xy-00.png}.

Correct, I have the images a figures folder, so the directive ended up being {figures/MRIL}

I think normally it should work unless you do something like using underscore package. graphics - Incompatibility of underscore package and includegraphics if there is an underscore in the file name - TeX - LaTeX Stack Exchange so it isn't really an issue with this package.


No HDMI input handshake

I'm having trouble getting HDMI input to work with base.video.hdmi_in in python (pynq API v2.0, had the same issue with 1.4):

Pynq's HDMI input is not detected by devices, therefore devices do not start streaming video data. base.video.hdmi_in consequently times out and raises an exception.

I managed to trick devices to start their HDMI output by using a DVI splitter (with HDMI-DVI adapters), connected to normal displays, and connecting one of the outputs of that splitter to the pynq.
I can then run all the video demos from the provided jupyter notebooks with 1080p 60fps input.

I believe you would have faced one or both of these problems:

PYNQ board doesn't have HDMI receiver LSIs. I experienced several PYNQ boards (and DVI2RGB IP in PYNQ) cannot sync with pixel clock provided by specific source devices (I doubt poor quality signals). In this case, PYNQ fails to start hdmi_in. Either of use of active HDMI cable or "retransmitting" the signal (using HDMI splitter, etc.) would resolve this issue.
I believe PYNQ-Z1 physical design needs to be changed for complete resolution. BTW I saw ZYBO Z7 boards have an LSI in HDMI RX.

DVI2RGB accepts DVI data format only. Though the IP has DDC ROM to ask the source for DVI data format (on the HDMI port) so it should work for most cases, some sources ignore DDC and transmit in HDMI data format that DVI2RGB cannot handle. In this case, DVI2RGB can lock the pixel clock but no inputs from HDMI port (VDE always 0.)
Your "HDMI to DVI converter" would have resolved the situation by forcing DVI format.
This branch has the changes, to accept HDMI video format with audio, working fine with Nintendo Wii U console.
https://github.com/hasegaw/PYNQ/commits/edid_for_wiiu
I don't know if PYNQ will support HDMI data formats in future releases.
Takeshi

Yes, future boards (and frontend IP) will support HDMI properly.  On PYNQ-Z1, its really DVI