text:
Should skipSupportsInterface be true for Diamond facets?

This issue was raised in https://github.com/wighawag/hardhat-deploy/pull/216 and marked solved, but I still get the error:
SkipSupportsInterfaceTest.sol:
pragma solidity 0.8.17;

contract SkipSupportsInterfaceTest {
    function supportsInterface(bytes4 _interfaceId) external pure returns (bool res) {
    }
}

Deployment script:
module.exports = async ({ getNamedAccounts, deployments }) => {
  const { diamond } = deployments;
  const { deployer } = await getNamedAccounts();

  await diamond.deploy("TestDiamond", {
    from: deployer,
    log: true,
    waitConfirmations: 1,
    facets: ["SkipSupportsInterfaceTest"],
  });
}

When I deploy I get this error: Error: function "supportsInterface" will shadow "supportsInterface". Please update code to avoid conflict.
I believe this would go away if skipSupportsInterface were set to true, and there would be no downside as supportsInterface isn't appropriate on facets anyway.
Thanks!

You ll have to provide your own Diamond contract as the one used by default as a builtin facet for supportsInterface

This actually was an issue not with your Diamond contract, which I believe handles this correctly, but rather with adding other people's base contracts that also define supportsInterface.
E.g., most ERC721 base contracts define it (even those that use Diamond Storage).
And then if you want ERC2981, the base contract you use probably defines supportsInterface as well, and so now you've got three definitions!
To resolve this I copy-pasted these base contracts into my code base and removed supportsInterface, leaving hardhat-deploy's contracts unchanged.
Not a super-clean solution, but I cannot think of another way as it is such a strong convention for base contracts to provide the correct supportsInterface!
However this issue might be good to mention in the README. Just a thought!

Ha ok, yes, one plan is to have a filter option to let you define what function should be exposed for each facet
That would solve your problem too. Thanks for clarifying

That would be amazing!!
This would also solve another infuriating scenario: I have a contract with 10 functions and one function has a bug. Currently I have to fix the bug, deploy a new contract with the fix, and then diamond cut away all of the old functions and add the new ones!
Ideally I would deploy a new contract with just one single fixed function and then put the buggy function on the "filter" list of the old contract, meaning that 9/10 functions of the old contract make it and 1/1 functions in the new contract do.
Thoughts? This is my true dream!

That would be amazing!!
This would also solve another infuriating scenario: I have a contract with 10 functions and one function has a bug. Currently I have to fix the bug, deploy a new contract with the fix, and then diamond cut away all of the old functions and add the new ones!
Ideally I would deploy a new contract with just one single fixed function and then put the buggy function on the "filter" list of the old contract, meaning that 9/10 functions of the old contract make it and 1/1 functions in the new contract do.
Thoughts? This is my true dream!

I added a PR, that allows filtering, that would work in your scenario like patching a single function

authors: RogerPodacter idkravitz wighawag

repo: wighawag/hardhat-deploy


text:
SWARM-1580: Jaeger Fraction: JAEGER_SAMPLER_PARAM should be parsed to…

SWARM-1580: JAEGER_SAMPLER_PARAM should be parsed to Number instead of iInteger

[ X] Have you followed the guidelines in our Contributing document?
[ X] Have you created a JIRA and used it in the commit message?
[ X] Have you checked to ensure there aren't other open Pull Requests for the same issue?
[ X] Have you built the project locally prior to submission with mvn clean install?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

source: gharchive/pull-request

authors: btison kenfinnigan wildfly-swarm-ci

repo: wildfly-swarm/wildfly-swarm

license_type: permissive

license_source: bigquery


text:
[WFCORE-5813] Eliminating unused CapabilityServiceBuilder.addInjection() method

https://issues.redhat.com/browse/WFCORE-5813

@ropalka thanks

authors: jmesnil ropalka

repo: wildfly/wildfly-core

license_source: github-api


text:
WFCORE-681 Incorrectly timeout values in ControllerLogger method time…

…outCompletingOperation and ControllerMessages method serviceInstallTimedOut
https://issues.jboss.org/browse/WFCORE-681
Incorrectly scaled timeout value passed to org.jboss.as.controller.ControllerLogger method timeoutCompletingOperation and org.jboss.as.controller.ControllerMessages method serviceInstallTimedOut
parameter value is ms, second is expected.

Core - Full Integration Build 930 is now running using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d

Windows Build 1338 is now running using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d

Linux Build 1778 is now running using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d

Windows Build 1338 outcome was FAILURE using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d
Summary: Tests failed: 7 (7 new), passed: 3094, ignored: 66 Build time: 0:22:12
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.manualmode.management.cli.CustomVaultInCLITestCase.testWrongVaultPassword: <no details avaliable>

org.jboss.as.test.manualmode.management.cli.CustomVaultInCLITestCase.testNonExistingVaultPassword: <no details avaliable>

org.jboss.as.test.manualmode.management.cli.CustomVaultInCLITestCase.testRightVaultPassword: <no details avaliable>

org.jboss.as.test.manualmode.vault.CustomVaultInModuleTestCase: <no details avaliable>

org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase.testWrongVaultPassword: <no details avaliable>

org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase.testRightVaultPassword: <no details avaliable>

org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.testTrustedCLICertificate: <no details avaliable>

Linux Build 1778 outcome was SUCCESS using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d
Summary: Tests passed: 3101, ignored: 66 Build time: 0:23:10

Core - Full Integration Build 930 outcome was FAILURE using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d
Summary: Tests failed: 1 (1 new), passed: 2867, ignored: 373 Build time: 0:52:33
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.integration.ejb.timerservice.mgmt.PersistentCalendarTimerManagementTestCase.testResourceExistence: <no details avaliable>


text:
[WFCORE-732] Extend tests for CLI commands extensibility

https://issues.jboss.org/browse/WFCORE-732 - Extend tests for CLI commands extensibility
Alexey added test as part of WFCORE-582. Adding two more tests.
command name conflict

try to register command with name of some standard CLI command
command is not registered

help message for custom command

add help message to the command from extension
verify, that help message is available

Adding tests as part of https://issues.jboss.org/browse/EAP7-91 verification procedure.

Linux Build 1912 is now running using a merge of 7150f680d58c086608270871ec92be3e9fe4738f

Windows Build 1465 is now running using a merge of 7150f680d58c086608270871ec92be3e9fe4738f

Core - Full Integration Build 1052 is now running using a merge of 7150f680d58c086608270871ec92be3e9fe4738f

Windows Build 1465 outcome was FAILURE using a merge of 7150f680d58c086608270871ec92be3e9fe4738f
Summary: Tests failed: 1 (1 new), passed: 3123, ignored: 71 Build time: 0:20:35
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.manualmode.management.cli.extensions.CliExtCommandsTestCase.testExtensionCommandHelp: <no details avaliable>

Linux Build 1912 outcome was SUCCESS using a merge of 7150f680d58c086608270871ec92be3e9fe4738f
Summary: Tests passed: 3124, ignored: 71 Build time: 0:23:18

Core - Full Integration Build 1052 outcome was SUCCESS using a merge of 7150f680d58c086608270871ec92be3e9fe4738f
Summary: Tests passed: 2888, ignored: 375 Build time: 0:50:22

I'll try to hunt down the Windows failure...

Core - Full Integration Build 1064 is now running using a merge of 4e30828191227a89b4940c2f7656c6a3e3ffc6bc

Windows Build 1477 is now running using a merge of 4e30828191227a89b4940c2f7656c6a3e3ffc6bc

Linux Build 1924 is now running using a merge of 4e30828191227a89b4940c2f7656c6a3e3ffc6bc

Windows Build 1477 outcome was SUCCESS using a merge of 4e30828191227a89b4940c2f7656c6a3e3ffc6bc
Summary: Tests passed: 3124, ignored: 71 Build time: 0:21:48

Linux Build 1924 outcome was SUCCESS using a merge of 4e30828191227a89b4940c2f7656c6a3e3ffc6bc
Summary: Tests passed: 3124, ignored: 71 Build time: 0:23:30

Core - Full Integration Build 1064 outcome was SUCCESS using a merge of 4e30828191227a89b4940c2f7656c6a3e3ffc6bc
Summary: Tests passed: 2871, ignored: 375, muted: 1 Build time: 0:49:26

I don't see why these test classes (including the existing stuff in CliExtCommandsTestCase) needs to be in manual mode (which is slower.) Unless you're aware of a good reason for this, can you file a JIRA to move them please? Thanks.
Otherwise, looks good.

You are right, these can be moved. I'll move them once this is merged.
https://issues.jboss.org/browse/WFCORE-766

authors: bstansberry pkremens wildfly-ci