text:
couldn't get slot allocation

Help me:
const client = new RedisClustr({
    servers: [
      {
        host: '127.0.0.1',
        port: 6379
      }
    ]
})
client.get(key, function (err, data) { console.log(err.message) }) // 'couldn't get slot allocation'

I know my local redis didn't support cluster mode. Is there a way to connect normal local redis?

using redis-6.2.5
I'm having this problem too. I setup my redis cluster with the script from the redis lib, utils/create-cluster/create-cluster. I added retry logic using async-retry with
const response = await retry(() => util.promisify(redis.set).bind(redis)(key, val));

and I added some debug logs to redis-clustr lib itself so I can see the problem appears to be that none of the connections have ready equal to true.
  redis-clustr tryClient() +30s
  redis-clustr getRandomConnection(): connections 6 +1ms
  redis-clustr getRandomConnection(): connections ready = 0 +0ms
  redis-clustr tryClient(): error - couldn't get slot allocation +0ms

The weird thing is is that I can connect to one of my redis clients of this cluster with redis-cli -c -p 30001 and run commands like cluster slots, keys *, set a 1, or get a just fine. I can run another local script using this redis-clustr lib locally calling get or set redis commands while my main app is retrying and failing to get a ready connection.

try using the minimal config from their example like:
    const RedisClustr = require('redis-clustr');
    const Redis = require('redis');

    const servers = [
      {
        "servers": [
          {
            "host": "127.0.0.1",
            "port": 30001
          },
          {
            "host": "127.0.0.1",
            "port": 30002
          },
          {
            "host": "127.0.0.1",
            "port": 30003
          },
          {
            "host": "127.0.0.1",
            "port": 30004
          },
          {
            "host": "127.0.0.1",
            "port": 30005
          },
          {
            "host": "127.0.0.1",
            "port": 30006
          }
        ]
      }
    ];

    const redis = new RedisClustr({
      servers,
      createClient: function(port, host) {
        // this is the default behaviour
        return Redis.createClient(port, host);
      }
    });

@everlose I have the same issue/limitation.
I believe with this library we have to have a redis-cluster not just a normal redis instance.
It would be good though to support backward-compatibility.

authors: everlose jtara1 menocomp

repo: gosquared/redis-clustr


text:
yaml escaping seen as string and not boolean

Describe the bug
if I escape the skip part I got and unmarshal error
visualstudio:
    exec: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe -nologo -version
    exit-status: 0
    stdout:
      - /16\.\d+\.\d+\.\d+/
    skip: '{{ not (eq .Env.AGENT_OS_VERSION "2019") }}'

export GOSS_USE_ALPHA=1; export AGENT_OS_VERSION=2022; goss -g ./goss/goss-windows.yaml render
2024/05/14 14:30:33 yaml: unmarshal errors:
  line 62: cannot unmarshal !!str `true` into bool

but if I don't escape then the yaml seems to be wrong as told by https://github.com/goccy/go-yaml/tree/master
(used within updatecli):
visualstudio:
    exec: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe -nologo -version
    exit-status: 0
    stdout:
      - /16\.\d+\.\d+\.\d+/
    skip: {{ not (eq .Env.AGENT_OS_VERSION "2019") }}

ERROR: something went wrong in target "updateJDK21VersionInGoss" : "updating yaml file: parsing yaml file: [62:12] unexpected mapping key\n      59 |     exit-status: 0\n      60 |     stdout:\n      61 |       - /16\\.\\d+\\.\\d+\\.\\d+/\n    > 62 |     skip: {{ not (eq .Env.AGENT_OS_VERSION \"2019\") }}\n                      ^\n      63 | file:\n      64 |   C:\\Program Files\\Chromium\\Application\\:\n      65 |     contains: []"

How To Reproduce
everything is public here : https://github.com/jenkins-infra/packer-images
from the goss file: https://github.com/jenkins-infra/packer-images/blob/main/goss/goss-windows.yaml
to one of the updatecli manifest that break if the skip line is not escape: https://github.com/jenkins-infra/packer-images/blob/main/updatecli/updatecli.d/jdk21.yml
export GOSS_USE_ALPHA=1; export AGENT_OS_VERSION=2022; goss -g ./goss/goss-windows.yaml render
updatecli diff --values ./updatecli/values.yaml --config ./updatecli/updatecli.d/jdk21.yml
Expected Behavior
that this version:
visualstudio:
    exec: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe -nologo -version
    exit-status: 0
    stdout:
      - /16\.\d+\.\d+\.\d+/
    skip: '{{ not (eq .Env.AGENT_OS_VERSION "2019") }}'

or
visualstudio:
    exec: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe -nologo -version
    exit-status: 0
    stdout:
      - /16\.\d+\.\d+\.\d+/
    skip: |
        {{ not (eq .Env.AGENT_OS_VERSION "2019") }}

manage to convert true or false string to boolean
Actual Behavior
error
line 62: cannot unmarshal !!str true into bool
Environment:

Version of goss goss version v0.4.2

Sounds like updatecli had/has the bug?

Sounds like updatecli had/has the bug?

not really, but depending on the yaml engine used, it's seen as wrong yaml ... the smart thing about updatecli is that you can choose your yaml engine

source: gharchive/issue

authors: aelsabbahy pilere smerle33

repo: goss-org/goss

license_type: permissive

license_source: github-api


text:
example/simple: progress bar scrolls terminal

hi,
looking at #3 and event after specifying the bar.Width to, say, 60:
$> git diff
diff --git a/example/simple/simple.go b/example/simple/simple.go
index d8d912b..2af47af 100644
--- a/example/simple/simple.go
+++ b/example/simple/simple.go
@@ -9,6 +9,7 @@ import (
 func main() {
        uiprogress.Start()            // start rendering
        bar := uiprogress.AddBar(100) // Add a new bar
+       bar.Width = 60

        // optionally, append and prepend completion and elapsed time
        bar.AppendCompleted()

I still get:
$> go run ./simple.go
    0 [----------------------------------------------------------]   1%
    0 [----------------------------------------------------------]   2%
    0 [----------------------------------------------------------]   2%
[...]
   1s [=========================================================>]  99%
   1s [=========================================================>]  99%
   1s [==========================================================] 100%
   1s [==========================================================] 100%

my terminal is rxvt:
$> echo $TERM
rxvt-unicode-256color

(but even with TERM=vt100, I get the above behaviour)
is there something I am doing wrong?

One thing I observed is if the terminal window is wide, this error does not occur.

authors: sammyrnycreal sbinet

repo: gosuri/uiprogress

license: mit

license_source: bigquery


text:
heapcheck locks up in pprof

Originally reported on Google Code with ID 656
What steps will reproduce the problem?

Invoking like this, will provide addresses with no symbols, as expected, since gperftools
doesn't look for pprof in the path for some reason:
env LD_PRELOAD=libtcmalloc.so HEAPCHECK=normal ./my_app

Invoking like this, will hang on program termination, just after printing "The N largest
leaks:":
env LD_PRELOAD=libtcmalloc.so PPROF_PATH=$(which pprof) HEAPCHECK=normal ./my_app

What version of the product are you using? On what operating system?
2.3rc, Ubuntu 10.04

Reported by bryce.schober on 2014-11-10 19:33:33

Closing stale ticket.

repo: gperftools/gperftools


text:
gperftools-2.5 + legacy python 2.7.5 + self built gcc-4.6.2 make check failure (profiler_unittest.sh)

make check fails on my old CentOS-5 x86_64 desktop with the attached
test-suite.log...
test-suite.log.txt

Attach your config.log please. I think you're likely configured without libunwind and we're automatically choosing libgcc and it isn't safe to use from cpu profiler signal handler.

you are right on spot :P
config.log.txt

Indeed, libgcc is used. It is not safe to use for profiling. But if you don't use profiling, it should work fine. So just ignore this make check failure.

Notably very latest OSes now make it safe and actually best & perfect to use libgcc instead of other means. And configure doesn't bark at libgcc anymore (even though some people are likely to use not recent enough OSes and have trouble).
Anyways. Closing.

authors: alk truatpasteurdotfr


text:
Feature request: support OauthConfiguration.RequireRegistration for applications

Please could support for the OauthConfiguration.RequireRegistration field in fusionauth Applications be added?
By itself it's a fairly easy change to make, along the lines of the following in resource_fusionauth_application_helpers.go:
// func buildResourceDataFromApplication
err = data.Set("oauth_configuration", []map[string]interface{}{
		{
			// Other fields omitted for brevity
			"require_registration":          a.OauthConfiguration.RequireRegistration,
		},
})

// func buildApplication
a := fusionauth.Application{
		// Other fields omitted
		OauthConfiguration: fusionauth.OAuth2Configuration{
			// Other fields omitted
			RequireRegistration:         data.Get("oauth_configuration.0.require_registration").(bool),
		},
}

The difficulty comes from the fact that this requires updating to the latest version of the Terraform Go client (field added in this commit), which introduces breaking changes to User two-factor auth (the twoFactorDelivery, twoFactorEnabled & twoFactorSecret fields are deprecated & were removed in v1.26.0).
I've attempted to make the changes myself - the RequireRegistration field works as expected but I keep running into issues determining whether to apply changes to two factor methods (this is my first time making any serious changes to a terraform provider). I'll happily submit a draft PR if nobody is already working on these changes & you think it would help

@MVJosh currently working on updates tot he provider. Will get this included. I didn't see it in the docs

Have this branch going https://github.com/gpsinsight/terraform-provider-fusionauth/pull/51

That's great, thanks for the update!
The RequireRegistration field isn't in the FusionAuth docs for some reason... (no idea why - probably just an oversight) but reading the code tells me it's definitely part of the API.
It's a little annoying they don't document it, since it defaults to false, which means any user with a FusionAuth account can access an application that hasn't had RequireRegistration set to true.

@MCBrandenburg issue submitted with the FA team to request docs update

Thanks for pointing that out @MVJosh we'll get that corrected.

authors: MCBrandenburg MVJosh robotdan


text:
Add new API permissions endpoints

Resolves #157

Thanks @sjauld !

source: gharchive/pull-request

authors: robotdan sjauld


text:
Slack Tool - When asking for recent message sent by a person in channel, i get DM messages.

Electron build- f8cb3bd
Steps to reproduce the problem:

Chat with Acorn Engineering assistant.
Ask for the most discussion from me in Engineering channel -  Get the most recent discussion by <current user> in Engineering channel

I get the response as a slack message that was a DM to someone and not the message from the Channel
Tool calls done in this case dont use the channel information provided.
 Input
"Get the most recent discussion by sangeetha in Engineering channel"

Messages
<tool call> searchUsers -> {"query":"sangeetha"}

<tool call> searchMessages -> {"query":"from:sangeetha","sort":"timestamp","sort_dir":"desc","count":"1"}

The most recent discussion by Sangeetha in the Engineering channel is as follows: > **Sangeetha**: When I mark issues as "High", I am having "help wanted" tag for you to review the priority as we had discussed. Wanted to let you know that I am not marking any issues as "Release Blockers". (9/5/2024, 5:02:30 PM) If you need more details or further assistance, feel free to ask!

maybe this can be improved by adding some examples to the query parameter

repo: gptscript-ai/desktop

license: MIT


text:
Outdated analyzer dependency on ferry_generator

Analyzer dependency on the generator is outdated:
https://github.com/gql-dart/ferry/blob/master/packages/ferry_generator/pubspec.yaml#L18
Starting to get conflicts with other packages.
Is there a reason it hasnt been updated in a while?

Theres a dependency on gql_code_builder.

How are others working around this issue? I'm reluctant to do a dependency_override in case that breaks it just wondering if anyone else has found a workaround for this

Did you end up doing it? If so, did you face any issues?

How are others working around this issue? I'm reluctant to do a dependency_override in case that breaks it just wondering if anyone else has found a workaround for this

Did you end up doing it? If so, did you face any issues?

Yea I ended up adding the following to my pubspec and everything has been working from what I can tell
dependency_overrides:
  ### Required due to https://github.com/gql-dart/ferry/issues/291
  analyzer: ^2.7.0

I'm curious if this repo is going will continue actively maintained going forward? Reason I ask is that the repo was receiving nearly daily commits up until September 9th then nothing since. Is there a dev branch or new project I'm not aware of?
Hope that my question doesn't come across the wrong way I'm genuinely curious what the future of the repository is going to be. I really appreciate all of the hard work everyone has put into this repo

duplicate of https://github.com/gql-dart/ferry/issues/282

I'm curious if this repo is going will continue to be actively maintained going forward?
I plan to continue to maintain ferry on a best-effort basis.

authors: KieranLafferty QuirijnGB ambiguous48 smkhalsa

repo: gql-dart/ferry


text:
📅 11/14 @ 12:30pm PT - code walkthrough: nock

💁🏻 code walkthrough: nock
📅 Sunday, November 14, 2021
🕐 12:30am Pacific Time
🎙 no guests
📍 https://www.twitch.tv/gregorcodes
🏷 opensource

Subscribe to this issues to get a notification before the show begins and a summary after the show concludes.
code walkthrough: nock
I've been a nock maintainers for several years now. We received a generous sponsorship a while ago which, with the support of my fellow maintainers, I'm now using to decompose the nock code base. You can follow updates at https://github.com/nock/nock/discussions/2247
Outline
This will probably be a 3-4h screencast.

I'll start out finishing the work on issue forms: https://github.com/nock/nock/pull/2248
After that, I'll dive into the code base to remind myself how it's all working together and what logic should be moved into its own modules

TODOs
Before the show

[x]  30 minute announcement tweet
(https://twitter.com/gr2m/status/1459973847160016897)
[x]  30 minute announcement comment
(https://github.com/gr2m/helpdesk/issues/53#issuecomment-968353676)

When show begins

[ ]     start of show tweet
[ ]  comment on issue
[ ]  Set twitter profile url

After the show

[ ]  Reset twitter profile after the show
[ ]  recording available tweet

Recording
will be added after the show

Shownotes
will be added after the show

Going live in 30 minutes at https://twitch.tv/gregorcodes

I'm now live on https://twitch.tv/gregorcodes

Here are the two recordings:

https://www.twitch.tv/videos/1205654930
https://www.twitch.tv/videos/1205809190

I'll post an update at https://github.com/nock/nock/discussions/2247

Satış toptan alışveriş mağazamız İstanbul Beyazıt[Ahmet Çakir] Instagram[karizma.00191]
(+905318950678)
ahmetcakir8200@gmail.com @gr2m


text:
Depending on task rules based tasks does not fully work with configuration avoidance

Given the task rules example from the documentation:
tasks.addRule("Pattern: ping<ID>") {
    val taskName = this
    if (startsWith("ping")) {
        task(taskName) {
            doLast {
                println("Pinging: " + (taskName.replace("ping", "")))
            }
        }
    }
}

The following works fine with Gradle 6.5.1:
val groupPing by tasks.registering {
    dependsOn("pingServer1", "pingServer2")
}

This also works fine:
val groupPing by tasks.creating {
    dependsOn(tasks.named("pingServer1"), tasks.named("pingServer2"))
}

But this does not work:
val groupPing by tasks.registering {
    dependsOn(tasks.named("pingServer1"), tasks.named("pingServer2"))
}

instead it throws this exception:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring root project 'foo'.
        at org.gradle.execution.TaskNameResolver.getExistingTask(TaskNameResolver.java:116)
        at org.gradle.execution.TaskNameResolver.access$000(TaskNameResolver.java:32)
        at org.gradle.execution.TaskNameResolver$MultiProjectTaskSelectionResult.collect(TaskNameResolver.java:177)
        at org.gradle.execution.TaskNameResolver$MultiProjectTaskSelectionResult.collectTasks(TaskNameResolver.java:169)
        at org.gradle.execution.TaskNameResolver.selectWithName(TaskNameResolver.java:55)
        at org.gradle.execution.TaskSelector.getSelection(TaskSelector.java:104)
        at org.gradle.execution.TaskSelector.getSelection(TaskSelector.java:82)
        at org.gradle.execution.commandline.CommandLineTaskParser.parseTasks(CommandLineTaskParser.java:42)
        at org.gradle.execution.TaskNameResolvingBuildConfigurationAction.configure(TaskNameResolvingBuildConfigurationAction.java:46)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:58)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$200(DefaultBuildConfigurationActionExecuter.java:26)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$2.proceed(DefaultBuildConfigurationActionExecuter.java:66)
        at org.gradle.execution.DefaultTasksBuildExecutionAction.configure(DefaultTasksBuildExecutionAction.java:45)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:58)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$200(DefaultBuildConfigurationActionExecuter.java:26)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$2.proceed(DefaultBuildConfigurationActionExecuter.java:66)
        at org.gradle.execution.ExcludedTaskFilteringBuildConfigurationAction.configure(ExcludedTaskFilteringBuildConfigurationAction.java:48)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:58)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$200(DefaultBuildConfigurationActionExecuter.java:26)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$1.run(DefaultBuildConfigurationActionExecuter.java:44)
        at org.gradle.internal.Factories$1.create(Factories.java:26)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry.withLenientState(DefaultProjectStateRegistry.java:134)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry.withLenientState(DefaultProjectStateRegistry.java:126)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.select(DefaultBuildConfigurationActionExecuter.java:40)
        at org.gradle.initialization.DefaultTaskExecutionPreparer.prepareForTaskExecution(DefaultTaskExecutionPreparer.java:38)
        at org.gradle.initialization.BuildOperatingFiringTaskExecutionPreparer$CalculateTaskGraph.populateTaskGraph(BuildOperatingFiringTaskExecutionPreparer.java:117)
        at org.gradle.initialization.BuildOperatingFiringTaskExecutionPreparer$CalculateTaskGraph.run(BuildOperatingFiringTaskExecutionPreparer.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:395)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:387)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:84)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.initialization.BuildOperatingFiringTaskExecutionPreparer.prepareForTaskExecution(BuildOperatingFiringTaskExecutionPreparer.java:56)
        at org.gradle.initialization.DefaultGradleLauncher.prepareTaskExecution(DefaultGradleLauncher.java:227)
        at org.gradle.initialization.DefaultGradleLauncher.doClassicBuildStages(DefaultGradleLauncher.java:159)
        at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:140)
        at org.gradle.initialization.DefaultGradleLauncher.executeTasks(DefaultGradleLauncher.java:120)
        at org.gradle.internal.invocation.GradleBuildController$1.create(GradleBuildController.java:74)
        at org.gradle.internal.invocation.GradleBuildController$1.create(GradleBuildController.java:67)
        at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:180)
        at org.gradle.internal.work.StopShieldingWorkerLeaseService.withLocks(StopShieldingWorkerLeaseService.java:40)
        at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:67)
        at org.gradle.internal.invocation.GradleBuildController.run(GradleBuildController.java:56)
        at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:31)
        at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
        at org.gradle.launcher.exec.BuildOutcomeReportingBuildActionRunner.run(BuildOutcomeReportingBuildActionRunner.java:63)
        at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
        at org.gradle.launcher.exec.BuildCompletionNotifyingBuildActionRunner.run(BuildCompletionNotifyingBuildActionRunner.java:39)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:51)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:45)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:409)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:399)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:94)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:45)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:50)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:47)
        at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:80)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:47)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:31)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:42)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:28)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:87)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:55)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:60)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:38)
        at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:68)
        at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:38)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:37)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:26)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:60)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:32)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:56)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:42)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:48)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:32)
        at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:68)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:39)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:29)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:35)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:78)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:75)
        at org.gradle.util.Swapper.swap(Swapper.java:38)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:75)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:50)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:63)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:82)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:52)
        at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: org.gradle.api.internal.tasks.DefaultTaskContainer$TaskCreationException: Could not create task ':groupPing'.
        at org.gradle.api.internal.tasks.DefaultTaskContainer.taskCreationException(DefaultTaskContainer.java:719)
        at org.gradle.api.internal.tasks.DefaultTaskContainer.access$600(DefaultTaskContainer.java:77)
        at org.gradle.api.internal.tasks.DefaultTaskContainer$TaskCreatingProvider.domainObjectCreationException(DefaultTaskContainer.java:711)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection$AbstractDomainObjectCreatingProvider.tryCreate(DefaultNamedDomainObjectCollection.java:948)
        at org.gradle.api.internal.tasks.DefaultTaskContainer$TaskCreatingProvider.access$1401(DefaultTaskContainer.java:658)
        at org.gradle.api.internal.tasks.DefaultTaskContainer$TaskCreatingProvider$1.run(DefaultTaskContainer.java:684)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:395)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:387)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:84)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.api.internal.tasks.DefaultTaskContainer$TaskCreatingProvider.tryCreate(DefaultTaskContainer.java:680)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection$AbstractDomainObjectCreatingProvider.calculateOwnValue(DefaultNamedDomainObjectCollection.java:929)
        at org.gradle.api.internal.provider.AbstractMinimalProvider.getOrNull(AbstractMinimalProvider.java:93)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection.findByName(DefaultNamedDomainObjectCollection.java:295)
        at org.gradle.api.internal.tasks.DefaultTaskContainer.findByName(DefaultTaskContainer.java:562)
        at org.gradle.api.internal.tasks.DefaultTaskContainer.findByName(DefaultTaskContainer.java:76)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection.getByName(DefaultNamedDomainObjectCollection.java:331)
        at org.gradle.api.internal.tasks.DefaultTaskCollection.getByName(DefaultTaskCollection.java:46)
        at org.gradle.execution.TaskNameResolver.getExistingTask(TaskNameResolver.java:114)
        at org.gradle.execution.TaskNameResolver.access$000(TaskNameResolver.java:32)
        at org.gradle.execution.TaskNameResolver$MultiProjectTaskSelectionResult.collect(TaskNameResolver.java:177)
        at org.gradle.execution.TaskNameResolver$MultiProjectTaskSelectionResult.collectTasks(TaskNameResolver.java:169)
        at org.gradle.execution.TaskNameResolver.selectWithName(TaskNameResolver.java:55)
        at org.gradle.execution.TaskSelector.getSelection(TaskSelector.java:104)
        at org.gradle.execution.TaskSelector.getSelection(TaskSelector.java:82)
        at org.gradle.execution.commandline.CommandLineTaskParser.parseTasks(CommandLineTaskParser.java:42)
        at org.gradle.execution.TaskNameResolvingBuildConfigurationAction.configure(TaskNameResolvingBuildConfigurationAction.java:46)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:58)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$200(DefaultBuildConfigurationActionExecuter.java:26)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$2.proceed(DefaultBuildConfigurationActionExecuter.java:66)
        at org.gradle.execution.DefaultTasksBuildExecutionAction.configure(DefaultTasksBuildExecutionAction.java:45)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:58)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$200(DefaultBuildConfigurationActionExecuter.java:26)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$2.proceed(DefaultBuildConfigurationActionExecuter.java:66)
        at org.gradle.execution.ExcludedTaskFilteringBuildConfigurationAction.configure(ExcludedTaskFilteringBuildConfigurationAction.java:48)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:58)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$200(DefaultBuildConfigurationActionExecuter.java:26)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$1.run(DefaultBuildConfigurationActionExecuter.java:44)
        at org.gradle.internal.Factories$1.create(Factories.java:26)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry.withLenientState(DefaultProjectStateRegistry.java:134)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry.withLenientState(DefaultProjectStateRegistry.java:126)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.select(DefaultBuildConfigurationActionExecuter.java:40)
        at org.gradle.initialization.DefaultTaskExecutionPreparer.prepareForTaskExecution(DefaultTaskExecutionPreparer.java:38)
        at org.gradle.initialization.BuildOperatingFiringTaskExecutionPreparer$CalculateTaskGraph.populateTaskGraph(BuildOperatingFiringTaskExecutionPreparer.java:117)
        at org.gradle.initialization.BuildOperatingFiringTaskExecutionPreparer$CalculateTaskGraph.run(BuildOperatingFiringTaskExecutionPreparer.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:395)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:387)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:84)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.initialization.BuildOperatingFiringTaskExecutionPreparer.prepareForTaskExecution(BuildOperatingFiringTaskExecutionPreparer.java:56)
        at org.gradle.initialization.DefaultGradleLauncher.prepareTaskExecution(DefaultGradleLauncher.java:227)
        at org.gradle.initialization.DefaultGradleLauncher.doClassicBuildStages(DefaultGradleLauncher.java:159)
        at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:140)
        at org.gradle.initialization.DefaultGradleLauncher.executeTasks(DefaultGradleLauncher.java:120)
        at org.gradle.internal.invocation.GradleBuildController$1.create(GradleBuildController.java:74)
        at org.gradle.internal.invocation.GradleBuildController$1.create(GradleBuildController.java:67)
        at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:180)
        at org.gradle.internal.work.StopShieldingWorkerLeaseService.withLocks(StopShieldingWorkerLeaseService.java:40)
        at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:67)
        at org.gradle.internal.invocation.GradleBuildController.run(GradleBuildController.java:56)
        at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:31)
        at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
        at org.gradle.launcher.exec.BuildOutcomeReportingBuildActionRunner.run(BuildOutcomeReportingBuildActionRunner.java:63)
        at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
        at org.gradle.launcher.exec.BuildCompletionNotifyingBuildActionRunner.run(BuildCompletionNotifyingBuildActionRunner.java:39)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:51)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:45)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:409)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:399)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:94)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:45)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:50)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter$1.transform(InProcessBuildActionExecuter.java:47)
        at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:80)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:47)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:31)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:42)
        at org.gradle.launcher.exec.BuildTreeScopeBuildActionExecuter.execute(BuildTreeScopeBuildActionExecuter.java:28)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:87)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:55)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:60)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:38)
        at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:68)
        at org.gradle.tooling.internal.provider.SessionScopeBuildActionExecuter.execute(SessionScopeBuildActionExecuter.java:38)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:37)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:26)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:60)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:32)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:56)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:42)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:48)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:32)
        at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:68)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:39)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:29)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:35)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:78)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:75)
        at org.gradle.util.Swapper.swap(Swapper.java:38)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:75)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:50)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:63)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:82)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:52)
        at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: org.gradle.api.internal.AbstractMutationGuard$IllegalMutationException: DefaultTaskContainer#create(String, Action) on task set cannot be executed in the current context.
        at org.gradle.api.internal.AbstractMutationGuard.createIllegalStateException(AbstractMutationGuard.java:39)
        at org.gradle.api.internal.AbstractMutationGuard.assertMutationAllowed(AbstractMutationGuard.java:27)
        at org.gradle.api.internal.DefaultDomainObjectCollection.assertMutable(DefaultDomainObjectCollection.java:452)
        at org.gradle.api.internal.tasks.DefaultTaskContainer.create(DefaultTaskContainer.java:337)
        at org.gradle.api.internal.tasks.DefaultTaskContainer.create(DefaultTaskContainer.java:76)
        at org.gradle.api.internal.project.DefaultProject.task(DefaultProject.java:1259)
        at Build_gradle$2.execute(build.gradle.kts:37)
        at Build_gradle$2.execute(build.gradle.kts:1)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection$3.apply(DefaultNamedDomainObjectCollection.java:474)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection.applyRules(DefaultNamedDomainObjectCollection.java:445)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection.findDomainObject(DefaultNamedDomainObjectCollection.java:782)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection.named(DefaultNamedDomainObjectCollection.java:358)
        at org.gradle.api.internal.tasks.DefaultTaskCollection.named(DefaultTaskCollection.java:112)
        at Build_gradle$groupPing$2.invoke(build.gradle.kts:52)
        at Build_gradle$groupPing$2.invoke(build.gradle.kts:1)
        at org.gradle.kotlin.dsl.TaskContainerExtensionsKt$sam$org_gradle_api_Action$0.execute(TaskContainerExtensions.kt)
        at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:42)
        at org.gradle.api.internal.DefaultMutationGuard$2.execute(DefaultMutationGuard.java:42)
        at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction$1$1.run(DefaultCollectionCallbackActionDecorator.java:100)
        at org.gradle.configuration.internal.DefaultUserCodeApplicationContext.reapply(DefaultUserCodeApplicationContext.java:60)
        at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction$1.run(DefaultCollectionCallbackActionDecorator.java:97)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:395)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:387)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:84)
        at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction.execute(DefaultCollectionCallbackActionDecorator.java:94)
        at org.gradle.internal.ImmutableActionSet$SingletonSet.execute(ImmutableActionSet.java:225)
        at org.gradle.api.internal.DefaultDomainObjectCollection.doAdd(DefaultDomainObjectCollection.java:264)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection.doAdd(DefaultNamedDomainObjectCollection.java:113)
        at org.gradle.api.internal.DefaultDomainObjectCollection.add(DefaultDomainObjectCollection.java:258)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection$AbstractDomainObjectCreatingProvider.tryCreate(DefaultNamedDomainObjectCollection.java:944)
        ... 125 more

Thank you for providing a valid reproducer.
The issue is in the backlog of the relevant team but the existence of a workaround makes it non-critical so it might take a while before a fix is made.

The workaround is to actually make sure that the ping* tasks are properly registered or to not use the named API for doing it.
This issue shows an inconsistency in the lazy task graph building however that should be addressed at some point.

authors: Vampire ljacomet

repo: gradle/gradle


text:
Provide a unified way to override task/extension properties

Expected Behavior
It is quite common to have tasks which have inputs which can be retrieved from Gradle properties or environment variables. As plugin authors, we have to think about providing options for everyone of them, or users cannot override from CLI.
A typical example involves setting a publication repository URL, or switching a flag. In Micronaut we also provide plugins which work on top of other plugins like docker, and for which we need to provide such cusmizations: https://github.com/micronaut-projects/micronaut-gradle-plugin/issues/271
So it would be ideal if Gradle would have an automatic mapping from CLI arguments and env variables to task/extension values. This is a domain where Maven is better compared to Gradle, since by default every single entry of a task maps to a property which can be overridden from CLI.
Current Behavior
Every plugin needs to define cumbersome code like value.convention(providers.systemProperty("...").forUseAtConfigurationTime().or(providers.environmentVariable("...").forUseAtConfigurationTime().or("foo"))
Alternatively, an annotation to mark what system properties override what property would also work, although it means that any non-annotated task would not work, which is kind of annoying. This would basically be about providing more to the @Option annotation:
@Option(option = "url", description = "Configures the URL to the repository")

I'm not sure if this annotation is supported on extensions, though. And there's also the problem that it won't work for existing tasks, that you'd want to make accessible.
Therefore, a conventional way to do it would be nice. Something like -Dtasks.publishToBuildRepo.url=... or -Dextensions.publishing.repositories.repository.maven.url=..., etc.
Context
Currently it's very difficult to provide support for overriding configuration from CLI or via tooling.

piiiing


text:
Ensure calculated durations are always non-negative

Difference between invocations of System.currentTimeMillis() cannot be trusted to calculate durations because it can produce a negative value due to how CPU clock synchronization occurs in various environments. See http://steveloughran.blogspot.fi/2015/09/time-on-multi-core-multi-socket-servers.html
Anytime we do this:
long start = System.currentTimeMillis();
… do stuff …
long timePassed = System.currentTimeMillis() - start;

We should use:
long start = System.nanoTime();
... do stuff ...
long timePassed = TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - start);

For actions that take fewer than 15 microseconds, you’ll sometimes notice that the difference between two reads of nanoTime() might be 0; however, it won’t produce negative values because it is always going to be monotonically increasing.
Expected Behavior
All durations calculations (e.g. those for build times) should never produce a negative value.
Current Behavior
We sometimes encounter negative durations during builds that negatively affects logic and produces inaccurate logs.
Context
This causes sporadic failures on Gradle CI, at the very least.

Note that

Something to be wary of when switching to use System.nanoTime(). From the Javadoc:
The values returned by this method become meaningful only when the difference between two such values, obtained within the same instance of a Java virtual machine, is computed.

In our dependency metadata cache, we record a timestamp value for each entry so that we can determine the age of the entry when using it later. While we are calculating a duration in this case, because this calculation is across JVMs, I don't think we can benefit from the monotonic clock of nanoTime.

I've made a change to handle backward clock-shift in dependency metadata checks. While not perfect, this change will help with the case where we set cacheChangingModulesFor 0, 'seconds' and a backward clock-shift occurs between the build that caches a dependency and a build that uses it. Previously, we'd reuse the cached dependency if it had a negative age: now if you say '0 seconds', we only use entries with age exactly zero (which is the case for entries created in the same build).

authors: bigdaz eriwen


text:
Error when setting "dimension" in Android

I'm using gradle-5.0-milestone-1 and 3.4.0-alpha03 on Android Studio 3.4 Canary 3, and Kotlin 1.3.10.
In Kotlin Scripts for build.gradle in the app version,
productFlavors {
    create("deploy") {
        dimension = "demo"
    }
    create("development") {
        dimension = "demo"
        minSdkVersion(24)
        resConfigs("en", "xxhdpi")
    }
}

The line dimension =X is underlined as an error saying Val cannot be assigned. But build, sync, and everything else works fine.

ProductFlavor.getDimension() return type is nullable but the parameter to ProductFlavor.setDimension(dim) isn't.
You can use the setter directly:
productFlavors {
    create("deploy") {
        setDimension("demo")
    }
}


text:
Update PMD plugin to latest 2.20.0

https://github.com/gradle/gradle/issues/11581

Updated PMD version from 2.17.0 to 2.20.0
Updated links in documentation
Updated upgrading notes

6.17.0 to 6.20.0, right?

authors: donat rieske


text:
Emphasize build result in console

Context
Fixes #1982
Contributor Checklist

[ ] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass locally: ./gradlew quickCheck <impacted-subproject>:check

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation including proper use of @since and @Incubating annotations for all public APIs

Normal Console

Plain Console

I added a new line before and after the build message.  The <=============> matches what the progress bar looks like when the build completes, so it has some nice symmetry.  But it also looks okay in the plain console (no progress bar).  I made the BUILD SUCCESSFUL message both bold, and green.
I expect some debate on this.  Thoughts @adammurdoch, @eriwen, @big-guy and anyone else?

@w25r what is the reasoning behind keeping a full progress bar around? Suppose the build failed halfway through.

It isn't a progress bar as much as just an indicator... I experimented with --------------------- and ====================== and I thought the best user experience was the length matching, rather than being longer.  And since ----- becomes ===== it led me to that.
I should add the failure image too.  I will do that now.

I'm still not sure what the bar is an indicator of. I think what we had is sufficient and we just need a little styling tbh

I think users might confuse <=============> or ============= with the progress bar. It simply looks too similar. We might be able to think about other ways to separate the build result based on feedback from end user. For now I'd just go with bold and green and push this PR through.

I've now bolded both BUILD FAILEDand BUILD SUCCESSFUL messages.
I also needed to do some refactoring to maintain passivity.  If the property org.gradle.color.failure is set to a color other than red, we need to continue to respect that setting.

authors: bmuschko eriwen w25r


text:
nested dependency declarations (DependencyHandler dynamic methods to return List<Dependency>)

Fixes #23452.
Context
This set of patches makes dependency declaration expressions that declare multiple dependencies return a list of the declared dependencies instead of null in order to allow nesting. This change makes dependency declaration more consistent and allows for cleaner dependency declarations by eliminating repetition.
Being able to configure the dependencies with a trailing Closure—albeit not a part of the issue—would be good too.
Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation

The patches raised a few errors while running :dependency-management:quickTest so I updated 4 tests. I've also tested
testImplementation(
	"org.junit.jupiter:junit-jupiter:latest.release",
	implementation(
		"org.ow2.asm:asm:latest.release",
		"org.ow2.asm:asm-tree:latest.release",
		api(
			"com.google.guava:guava:31.1-jre",
			"com.google.code.gson:gson:latest.release"
		)
	)
)

in a separate project and it works without issues.
Should I add tests and documentation?

Sorry, I don't think we want to do this as I described in the issue #23452

authors: auoeke big-guy


text:
Enable persistent compiler daemons by default

refs #25425

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.

authors: big-guy bot-gradle


text:
Fix some minor WorkerExecutor documentation issues

Remove WorkerExecutor from the DSL page (not a good fit)
Change the samples to use the params() method instead of the setter to avoid possible issues with @CompileStatic

LGTM

authors: big-guy ghale


text:
Try embedded Kotlin to 1.9.20 preview versions

https://github.com/JetBrains/kotlin/releases/tag/v1.9.20-Beta
https://github.com/JetBrains/kotlin/releases/tag/v1.9.20-Beta2
https://github.com/JetBrains/kotlin/releases/tag/v1.9.20-RC

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test this APT

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build
AllPerformanceTestsReadyForRelease build

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test APT

I've triggered the following builds for you. Click here to see all build failures.

AllPerformanceTestsReadyForRelease build

I've triggered the following builds for you. Click here to see all build failures.

AllSmokeTestsPullRequestFeedback build
AllPerformanceTestsReadyForRelease build

Superseded by https://github.com/gradle/gradle/pull/26889

authors: bot-gradle eskatos


text:
Rename Gradle Enterprise to Develocity in docs

This PR renames Gradle Enterprise to Develocity in remaining elements of user guide and header/footer.
Context

Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

I've triggered a build for you. Click here to see all failures if there's any.

authors: bot-gradle welandaz


text:
Fix CC incompatibility in Kotlin model building

by avoiding capturing of the project reference in an onConfigure action

@bot-gradle test without pts

I've triggered the following builds with parameters: -DenablePredictiveTestSelection=false for you. Click here to see all build failures.

PullRequestFeedback build

I've triggered a build for you. Click here to see all failures if there's any.

authors: alllex bot-gradle


text:
Merge release into master

Merges PR https://github.com/gradle/gradle/pull/29952 into master.

The merge queue build has failed. Click here to see all failures.

The merge queue build has failed. Click here to see all failures.

The merge queue build has failed. Click here to see all failures.

authors: blindpirate bot-gradle


text:
Added a preferProjectModules option to ResolutionStrategy

Any of the checked boxes below indicate that I took action:

[x] Reviewed the Contribution Guidelines.
[x] Signed the Gradle CLA.
[x] Ensured that basic checks pass: ./gradlew quickCheck

For all non-trivial changes that modify the behavior or public API:

[x] Before submitting a pull request, I started a discussion on the
Gradle developer list
or can reference a JIRA issue.
[x] I wrote a design document. A design document can be
brief but explains the use case or problem you are trying to solve,
touches on the planned implementation approach as well as the test cases
that verify the behavior. Optimally, design documents should be submitted
as a separate pull request. Samples
can be found in the Gradle GitHub repository. Please let us know if you need help with
creating the design document. We are happy to help!
[x] The pull request contains an appropriate level of unit and integration
test coverage to verify the behavior. Before submitting the pull request
I ran a build on your local machine via the command
./gradlew quickCheck <impacted-subproject>:check.
[x] The pull request updates the Gradle documentation like user guide,
DSL reference and Javadocs where applicable.

This s squashed version of https://github.com/gradle/gradle/pull/635.
The test was moved to a separate class.

Thank you for your pull request.
I am sorry to say that we do not have the capacity to look at this now. We will come back to you in a few weeks. Thank you for your patience.

Hey @idlsoft, thanks for all your work on this. Unfortunately with Gradle Summit looming, preparing for Gradle 3.0, and a problematic 2.14 release, we're stretched a bit thin at the moment.
You haven't been forgotten and this PR is in our queue of stuff to deal with. As @wolfs said, thanks for your patience while we get back on track.

Looks like this has been also requested in the forums: https://discuss.gradle.org/t/project-dependencies-participate-in-conflict-resolution/18875

Internal review: https://code-review.gradle.org/cru/REVIEW-6257

@idlsoft we finally integrated this. Thanks for the effort you invested in this and for your patience!
This feature will be part of the Gradle 3.2 release.

This is great, thank you!
Btw the reason the PR originally had preferProjectModules as a property was to be able to set it to false, so that if the default ever changes no additional public interface modifications would be necessary.

authors: bigdaz idlsoft jjohannes wolfs


text:
help to create a group by querie

Hello, we used to use the first druid plugin for Grafana (https://github.com/societe-generale/druidplugin ) and as you can see when we do a group by (or topn) query , Druid give us 2 metrics : one for each series

When we try do to the same with your plugin, the asnwer is only one metric instead of 2, when we used the graph panel. We don't understand why because when we do the same query with a table panel panel, we can see all the data. For example :

Best regards.

Hello @philippesg
Thank you!
Could it be that the response is "long" formatted instead of "wide"? (related: https://grafana.com/docs/grafana/latest/developers/plugins/data-frames/#data-frames-as-time-series )
To adjust the format, you may check it out:

Hope that helps!
NB: we could eventually default the format to "wide" (since it's probably most used) instead of long (here: https://github.com/grafadruid/druid-grafana/blob/master/pkg/druid.go#L750)

Hello @jbguerraz ,  it's exactly the problem, i changed the format to "wide" instead of long and i'm seeing the 2 series of data.
Thank very much.

authors: jbguerraz philippesg

repo: grafadruid/druid-grafana


text:
Support managing loki

It would be great to allow grafana-operator to also manage the various components of loki.

I've had a quick look and I think Loki and Promtail could run as sidecar containers in the Grafana Pod. So this should already be possible by using the containers field of the Grafana CR. If you need to mount extra configuration you could store it in a secret and mount it to a volume using the secrets field.
We use this mechanism to add an Oauth proxy in front of Grafana, see our example.
If you'd like to try out adding Loki in this way i'd be very interested in the result.

I don't think,  that's going to be enough.  To ingest logs from the whole cluster (or at least parts of the container) one needs a sidecar in any container or preferably running promtail once on each node, reading docker or runc logs directly.  I also think the operator should manage each Loki part separately to allow to scale it separately.
I tend to think that it makes sense to integrate loki in grafana operator, because it will benefit from integration of Loki in Grafana, but maybe it's not in scope.  What do you think?  I might be able to contribute.

I see, so ideally Loki would run in its own Pod to scale it independently of Grafana? That makes sense. Its not currently on our Roadmap but if you want to contribute you're very welcome. If there is an extra Pod independent of the Grafana Pod then i think we also need a Loki CR similar to the Grafana CR.
The Prometheus Operator can be taken as an example: it not only manages Prometheus instances but also Alertmanager which runs in a separate Pod.

We are currently discussing how to solve this issue. Our current plan points towards having a separate operator loki and grafana. You can find more information here: https://github.com/grafana-operator/grafana-operator/issues/497
A RedHat team have already started working on a loki operator, https://github.com/ViaQ/loki-operator please have a look and try it out.
Them and us would love feedback.
ping @ibotty

Oh, interesting.  I did not see the other operator.  I am fine either way.  I thought it made sense to bundle them together because it's nice to have the same label config from the same source.

It's rather new so it's nothing strange with that.
Fully understandable but we think it will be easier to maintain them as separate operators.
We are just in the starting pits on how to manage this in the future, but we will defiantly take a look at the loki operator API and try to get it as similar as possible to the grafana-operator. This might of course include changes to the grafana-operator as well, but the more feedback we can get the better.

@ibotty We've decided to close this issue off, as we'll be moving to a more plug-n-play approach with the Loki and Promtail operators, please feel free to leave your feedback here based on your evaluation of the viaq Loki operator, we'd love to hear your thoughts on this as we'll be evaluating this soon ourselves as well. Thanks!

authors: HubertStefanski NissesSenap ibotty pb82

repo: grafana-operator/grafana-operator


text:
loki.source.api (and prometheus.receive_http?) used to collect telemetry from network should send headers to backend

Request
loki.source.api and prometheus.receive_http used to collect telemetry from network should support authentication and/or at least forward received Authoriztion and X-Scope-OrgID headers to backends.
Use case
I was trying to use Grafana Agent and the components mentioned to collect metrics and logs from several agents on the network and send to two backend. The backend expect Authorization and/or X-Scope-OrgID headers to insert data in the proper tenant.
It seems that the two components doesn't support authentication by themselves and, despite having an authenticating reverse proxy in front correctly sending Authorization and X-Scope-OrgID, they doensn't forward these headers to backend endpoint, making impossible to push data in proper, variable, tenant.
Any other component recommended to do this?

The ability to convert certain HTTP headers to labels would also be useful to identify different teams sending metrics to central Alloy clusters in larger environments.

authors: nofoxsteven outofsight

repo: grafana/alloy


text:
Add latest to all the things

What this PR does / why we need it:
adding @latest to npx commands to avoid issues with local caching. Ref: https://github.com/npm/cli/issues/2329

Great stuff. Can we update the docusaurus website docs too please?

we certainly can and should https://github.com/grafana/plugin-tools/pull/208/commits/ba32fb69e727458c672c3c51e4c3e679cfce9a36

repo: grafana/plugin-tools


text:
Apply CRDs first

Similar to #489 CRDs should be applied first (just like namespaces should go before other resources)

In https://github.com/grafana/tanka/blob/master/pkg/process/sort.go we already sort CRDs before most other meaningful objects – so technically there should not be any order dependencies.
I could imagine that kubectl still disregards this and CRDs need to be applied fully separate – could you check that?
Using the following is a very good workaround:
$ tk apply -t 'CustomResourceDefinition/.+' . # first run, crds only
$ tk apply . # second run, everything

I guess we could detect that and automatically apply crds in a separate run. Wdyt?

In https://github.com/grafana/tanka/blob/master/pkg/process/sort.go we already sort CRDs before most other meaningful objects – so technically there should not be any order dependencies.
I could imagine that kubectl still disregards this and CRDs need to be applied fully separate – could you check that?
Using the following is a very good workaround:
$ tk apply -t 'CustomResourceDefinition/.+' . # first run, crds only
$ tk apply . # second run, everything

I guess we could detect that and automatically apply crds in a separate run. Wdyt?

ya, your work around is something I will likely implement locally, maybe it should be in the docs? The main problem I think is that diff will fail because the kubernetes API won't understand the CRD until CRD is applied. So the client has to apply CRD's first.

Not stale

I just ran into this. There really should be a mechanism that applies the crds first before doing initial diff.

I'd say this is a duplicate of https://github.com/grafana/tanka/issues/246.

authors: Duologic ghostsquad kubaracek sh0rez

repo: grafana/tanka


text:
v1: Add upgrade occurrence and note type.

This type represents a available software upgrade for a given resource
url. It is complementary to the package and vulnerability types.

We're waiting for @aysylu to LGTM this as well.

authors: clrprod vtsao

repo: grafeas/grafeas


text:
Type check gql with gql.tada

Learnt today that https://gql-tada.0no.co can type check GraphQL document strings via a TS template literal parser. It would be great to leverage that to type check Graffle's .gql method.
Investigate this.

https://bsky.app/profile/kuhrt.me/post/3lbkstitpls2z

repo: graffle-js/graffle


text:
MakeM4B.py doesn't observe config parameters for ChapterTool Path

MakeM4B.py doesn't observe config parameters for ChapterTool Path, it assumes ChapterTool.

RIP ChapterTool

authors: grahams seanth

repo: grahams/nicecast-trackupdate


text:
Update dependency on spring-ldap, spring-security-core, fix compiler warning

The spring-security-core plugin now uses 3.2.6.RELEASE, spring-security-ldap should too.

Thanks for the PR, but the updates have been made independently

authors: burtbeckwith tcrossland


text:
🛑 Grambling State University is down

In e9e57b2, Grambling State University (https://www.gram.edu) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Grambling State University is back up in a907375 after 1 hour.

repo: gramblingstatewebmaster/upptime


text:
TiFragmentPlugin

Plugin for Fragments using the new TiFragmentDelegate

Besides the tests it looks good, that'll make my life easier with the integration

LGTM

authors: StefMa passsy vRallev

repo: grandcentrix/ThirtyInch


text:
bbox is missing when query points are identical

This query fails https://graphhopper.com/maps2/?point=51.338454%2C12.378639&point=51.338454%2C12.378639&profile=car
because when the start/target points are identical the response path is missing the bbox field. See also here: https://github.com/graphhopper/graphhopper-maps/pull/87#issuecomment-865210402

This will be (also) fixed on the server side: https://github.com/graphhopper/graphhopper/pull/2348

There is now no error anymore. So closing. The zoom is still to high but this is another issue #53.

authors: easbar karussell

repo: graphhopper/graphhopper-maps


text:
App crashes when changing windows size

When the app is opened in a mobile layout and the window is resized to a larger window the app crashes and the entire browser window becomes unresponsive.
This does not happen everytime, unfortunately.
This happens in Fireforx and not in Chrome.

This is in Firefox on MacOS


text:
Fix error in rrd2whisper

I think there is an error in rrd2whisper.py where datasources can be empty in case rrd_info contains 'ds'.

@SEJeff @mleinart Can one of you guys review this? I'm an idiot when it comes to RRD anymore.

@obfuscurity This one seems like merely a typo, datasource_names appears only once in the whole file, not being referenced anywhere.
It's pretty sad that a PR like this remained open for almost two years and a half...

Ugh yeah, this is an obvious fix. Sorry for not noticing the ping months and months and months ago...

authors: mandre mleinart obfuscurity ushuz

repo: graphite-project/whisper


text:
chore: attempting to fix renovate for arbitrum releases

Not 100% why renovate if not picking up new releases for arbitrum - both docker pull docker.io/offchainlabs/arb-node:"v1.4.5-e97c1a4" and  docker pull offchainlabs/arb-node:"v1.4.5-e97c1a4" work so decided to try this

This has been fixed by https://github.com/graphops/launchpad-charts/pull/182

authors: calinah cjorge-graphops

repo: graphops/launchpad-charts


text:
Hosted service new deployment not syncing

Do you want to request a feature or report a bug?
bug
What is the current behavior?
after successful deployment, syncing got stuck
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
https://thegraph.com/explorer/subgraph/synfutures/erc7?version=pending
What is the expected behavior?
3/23/2021, 8:16:40 PM

DEBUG

Trying again after object.stat failed (attempt #4) with result Err(Uncategorized("\r\n<title>504 Gateway Time-out</title>\r\n\r\n
504 Gateway Time-out
\r\n
nginx/1.19.6\r\n\r\n\r\n"))

3/23/2021, 8:16:10 PM

DEBUG

Trying again after object.stat failed (attempt #3) with result Err(Uncategorized("\r\n<title>504 Gateway Time-out</title>\r\n\r\n
504 Gateway Time-out
\r\n
nginx/1.19.6\r\n\r\n\r\n"))

3/23/2021, 8:15:09 PM

DEBUG

Trying again after object.stat failed (attempt #1) with result Err(Uncategorized("\r\n<title>504 Gateway Time-out</title>\r\n\r\n
504 Gateway Time-out
\r\n
nginx/1.19.6\r\n\r\n\r\n"))

Same.. In my case, it gets stuck with 90.8% and then, after an hour or 2, succeeds.
Hope it will be resolved soon.

Normally, if there is an bug in the mappings, syncing would turn into "Failed" state with some error logs telling us what's wrong. But in my case there is no errors, and it just got stuck forever :(

Same....
I can not event deploy the hello world of the docs with small change.

Same here, it reaches 99.9% but does not become the current version. No errors, warnings, Infos found.

Please provide links to the subgraphs on the explorer so we can better investigate this issue.

Mine is the same:
Here is the link:
https://thegraph.com/explorer/subgraph/creaton-io/creaton2

I have confirmed that we have an issue were the graph nodes sometimes stop receiving new deployments, requiring a restart of the nodes. I have reset all nodes so the current incident should be resolved. Until we root cause this, please report on Discord if this happens again.

Seems that the restart unlocked the current pending version (with correct logging) but the same issue reappears if I try to re-deploy.

This is resolved now. Thanks for the prompt response @leoyvens

Er... this is still happening to people I think @leoyvens

Could you provide an example of a subgraph where this is still happening?

@lutter Thanks for the reply:
https://thegraph.com/explorer/subgraph/synfutures/erc7?version=pending

@qbig that subgraph seems to be making progress, what is the issue?

@lutter wow！Thanks for the tip! Removing ethereum calls works. However, this is kinda related to https://github.com/graphprotocol/graph-node/issues/2314 because without filter, I would be making calls for every block :(

@lutter  another issue is this, as new deployments is ignored.
quote @leoyvens
I have confirmed that we have an issue were the graph nodes sometimes stop receiving new deployments, requiring a restart of the nodes. I have reset all nodes so the current incident should be resolved. Until we root cause this, please report on Discord if this happens again.

@qbig That incident has been resolved, are you still having issues with new deployments?

Please open a new issue if necessary.

I have same issue with my subgraph. In the matic network.
https://thegraph.com/legacy-explorer/subgraph/itsib/spaceport-subgraph-polygon

Hello, my subgraph seems to be stuck while deploying and there seem to be no error logs etc. - https://thegraph.com/hosted-service/subgraph/yohanelly95/razor?version=pending
Are there any suggestions on anything I can do?

Hello, my subgraph seems to be stuck while deploying and there seem to be no error logs etc. - https://thegraph.com/hosted-service/subgraph/yohanelly95/razor?version=pending
Are there any suggestions on anything I can do? cc @leoyvens

@yohanelly95 we had an issue with one of the index nodes earlier. It looks like your subgraph is processing again.

Hello, my subgraph seems to be stuck while deploying and there seem to be no error logs etc. - https://thegraph.com/hosted-service/subgraph/yohanelly95/razor?version=pending
Are there any suggestions on anything I can do? cc @leoyvens

@yohanelly95 we had an issue with one of the index nodes earlier. It looks like your subgraph is processing again.

yes it is, I just had to redeploy a few times. Thanks again 🥇

@leoyvens I have tried redeploying many times, also waited for a week but syncing stopped at 68.3% is there any possible way to overcome this issue here is my link https://thegraph.com/hosted-service/subgraph/sid5494/fantom?version=pending. Are there any suggestions on anything I can do?

https://thegraph.com/hosted-service/subgraph/muzikanto/mf-nft

I have confirmed that we have an issue were the graph nodes sometimes stop receiving new deployments, requiring a restart of the nodes. I have reset all nodes so the current incident should be resolved. Until we root cause this, please report on Discord if this happens again.

Hey there, I'm having a similar issue with fantom network.
https://thegraph.com/hosted-service/subgraph/decentraworlddewo/fantom-demix-subgraph
Is there anything I can do about it? I've tried re-deploying but the same issue occurs.

Bump. I'm getting this issue on AVAX Fuji.

authors: DecentraWorldOfficial Muzikanto hzz780 itsib leoyvens lutter m30m milonite mtwichan novaknole qbig sid5494 yohanelly95

repo: graphprotocol/graph-node


text:
indexer-agent: Indexer rules update triggers immediate deployment allocation reconciliation

Currently indexing rule updates do not immediately trigger reconciliation and the delayed response causes distrust of the agent and encourages taking actions outside the agent.  Rule change events should lead to immediate reconciliation and, if applicable, on-chain action.

@fordN any idea on how this will be addressed?
IMO, the largest issue with this delayed response is with on-chain events (closing / opening allo's). If there is a lot of required work to make the rule change events immediate, could an interim solution be to have the agent default: 120_000 ms loop time configurable as seen in this update to the service nodes (https://github.com/graphprotocol/indexer/pull/229/commits/568df2610f25e4b56c837e05defd696b9d780f58) ?
Would there be any negative effects to making the reconciliation loop quicker as opposed to the 2 minutes?

@Aderks this issue has been resolved with the merging of #352 and will be included in the next release.

authors: Aderks fordN

repo: graphprotocol/indexer


text:
Issue with special characters (German Umlaute) when upgrading to 6.0.0 version

I detected an issue with special chars (e.g. German Umlaute) when upgrading my project to 6.0.0 version.
Sample GraphQL schema where Person.displayName can contain data with  special chars (e.g. German Umlaute)
type Person {
    id: ID!
    displayName: String!
    subtyp: String!
}

type Query {
    findById(id: Int): Person!
}

The following query works and returns correctly formatted JSON
{
  findById(id: 2000) {
    id
  }
}

Result OK
{
    "data": {
        "findById": {
            "id": "2000"
        }
    }
}

When adding  Person.displayName
{
  findById(id: 2000) {
    id
    displayName
  }
}

Result NOK (last closing parenthesis missing).
{
    "data": {
        "findById": {
            "id": "2000",
            "displayName": "Müller Alfred"
        }
    }

Same issue when response JSON is an array of objects.
It looks like this issue is not present on 5.10.0

Duplicate of #308


text:
introduce typescript, tsx, jsx support to LSP server using babel parser, with tests

introduces typescript, tsx and jsx support via babel parser plugins
#1263 by @zth is an alternative to solving this problem which also supports reasonml, and potentially other  a non-ast branch by @zth using regular expressions should  be reconsidered.
-tests for typecript and tsx added
getQueryAndRange changed to parseDocument, and made override-able as parse by startServer.

Does this do the same job as https://github.com/Quramy/ts-graphql-plugin?
If yes, are there any usage docs that I can refer to? 🤔

yes! the only difference now is that it will handle ts/tsx files when you open them. still need to get vscode workspaces configured correctly to read all the embedded graphql

to add, the typescript language plugin is still valuable for a lot of cases.

This looks good to me! This will allow people who want to support other languages than the mainstream ones (like ReasonML for me) to do that through replacing parseDocuments.  👍

@zth last commit here fixes that bug i saw in discord, otherwise looks like everything is working fine! I've had some issues with setting up our example extension, but i think i understand what I'm missing after working with yours and @divyenduz 's more carefully.

authors: acao divyenduz zth

repo: graphql/graphiql


text:
migrate rfc to examples workspace, out of yarn workspace

this reduces the yarn lockfile by almost 4k lines 👀
it also frees us up from weird resolutions caused by this awesome and useful but essentially now an artefect/point of reference

One of these days we won't even have babel in this repo! such lean deps we will have! 😍


text:
Change install include files

Install only C/C++ headers.
Also fixes missing headers (location.hh, etc.) when including in own files.

I tested again and seems to work without flags, did you use any?
Can you test again? It was probably the CMAKE_CURRENT_BINARY_DIR variable messing up

OK, now the C directory is getting created, but the generated headers (e.g., c/GraphQLAst.h) aren't included:
$ find
.
./include
./include/graphqlparser
./include/graphqlparser/AstNode.h
./include/graphqlparser/c
./include/graphqlparser/c/GraphQLAstNode.h
./include/graphqlparser/c/GraphQLAstVisitor.h
./include/graphqlparser/c/GraphQLParser.h
./include/graphqlparser/GraphQLParser.h
./include/graphqlparser/JsonVisitor.h
./include/graphqlparser/lexer.h
./include/graphqlparser/location.hh
./include/graphqlparser/position.hh
./include/graphqlparser/stack.hh
./include/graphqlparser/syntaxdefs.h
./lib
./lib/libgraphqlparser.dylib

I tested using an out-of-tree build: mkdir build && cd build && cmake .. -Dtest=1 -DCMAKE_INSTALL_PREFIX:PATH=/Users/swolchok/libgraphqlparser/install && cmake --build .

I think the problem is that the GLOB method can't really support out-of-tree builds. I'll send out a change to at least include the .hh files.

I just pushed https://github.com/graphql/libgraphqlparser/commit/3675c74bf6f4249bf6d32708073c0f401b92c32e to install the missing headers. Feel free to rebase and get this working with out-of-source builds!

closing because this has gone stale; feel free to open another PR

authors: kurayama swolchok

repo: graphql/libgraphqlparser


text:
How might I test a Microsoft Teams / Bot Framework bot built with Botkit with botkit-mock?

Hey all,
I am building a bot for Microsoft environments via Botkit (since they now support the Bot Framework), but I am unsure of how to test properly. Do you mind providing me a very basic example? Thanks!

hey @fbessez would you could simple example of your code?

Of course, just for a basic help message that returns a Rich Card / Adaptive Card
controller.hears('help', 'message_received', MiscUtls.help
MiscUtils.help = (bot, message) => { 	const reply = { 		attachments: [ 		{ 			contentType: "application/vnd.microsoft.card.adaptive", 			content:  				{ 					type: "AdaptiveCard", 					body: [ 					{ 						type: 'TextBlock', 						text: 'Log Work', 						size: 'large', 						weight: 'bolder' 					}, 					{ 						type: 'TextBlock', 						text: 'You can log work on JIRA issues. Select an issue from the issue dropdown, enter the time spent on the issue, then write a short description of what you did.', 						size: 'normal', 						weight: 'normal', 						separation: 'none', 						wrap: true 					}, 					{ 						type: 'TextBlock', 						text: 'Get Timesheet', 						size: 'large', 						weight: 'bolder' 					}, 					{ 						type: 'TextBlock', 						text: 'You can retrieve a link to your Tempo timesheet and view its status and the total number of hours logged. Click the link to continue working on your Timesheet in JIRA.', 						size: 'normal', 						weight: 'normal', 						separation: 'none', 						wrap: true 					} 					] 				} 			}] 		} 	bot.reply(message, reply); };
Does that help? Thank you!

Hey, yeah we'll take a look at this. I believe we can add an extender as
seen in our readme. I'll talk it over with ihor and we'll get back to you
ASAP.
On Thu, Jul 6, 2017 at 5:39 AM fabien bessez notifications@github.com
wrote:

Of course, just for a basic help message that returns a Rich Card /
Adaptive Card
controller.hears('help', 'message_received', MiscUtls.help
MiscUtils.help = (bot, message) => { const reply = { attachments: [ {
contentType: "application/vnd.microsoft.card.adaptive", content: { type:
"AdaptiveCard", body: [ { type: 'TextBlock', text: 'Log Work', size:
'large', weight: 'bolder' }, { type: 'TextBlock', text: 'You can log work
on JIRA issues. Select an issue from the issue dropdown, enter the time
spent on the issue, then write a short description of what you did.', size:
'normal', weight: 'normal', separation: 'none', wrap: true }, { type:
'TextBlock', text: 'Get Timesheet', size: 'large', weight: 'bolder' }, {
type: 'TextBlock', text: 'You can retrieve a link to your Tempo timesheet
and view its status and the total number of hours logged. Click the link to
continue working on your Timesheet in JIRA.', size: 'normal', weight:
'normal', separation: 'none', wrap: true } ] } }] } bot.reply(message,
reply); };
Does that help? Thank you!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gratifyguy/botkit-mock/issues/29#issuecomment-313347824,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACKLHtoUYOnnkEawKaTv6WtqQ4zcyCIQks5sLKszgaJpZM4OPX9k
.

Sweet, thank you!

Your main entry point app.js

var Botkit = require('botkit');
var controller = Botkit.botframeworkbot({
  debug: true
});

// Create the Botkit controller, which controls all instances of the bot.
var bot = controller.spawn({
  appId: process.env.app_id,
  appPassword: process.env.app_password
});

require('./indexController')(controller);

Logic of actions (indexController.js):
var MiscUtls = {};

MiscUtls.help = (bot, message) => {
  const reply = {
    attachments: [{
      contentType: "application/vnd.microsoft.card.adaptive",
      content: {
        type: "AdaptiveCard",
        body: [{type: 'TextBlock', text: 'Log Work', size: 'large', weight: 'bolder'}, {
          type: 'TextBlock',
          text: 'You can log work!',
          size: 'normal',
          weight: 'normal',
          separation: 'none',
          wrap: true
        }, {type: 'TextBlock', text: 'Get your time', size: 'large', weight: 'bolder'}, {
          type: 'TextBlock',
          text: 'Time.',
          size: 'normal',
          weight: 'normal',
          separation: 'none',
          wrap: true
        }]
      }
    }]
  };
  bot.reply(message, reply);
};

module.exports = function (controller) {
  controller.hears('help', 'message_received', MiscUtls.help)
};

tests:
'use strict';
const assert = require('assert');
const Botmock = require('botkit-mock');
const fileBeingTested = require("./indexController");

describe("controller tests", () => {
  afterEach(() => {
    //clean up botkit tick interval
    this.controller.shutdown()
  });

  beforeEach(() => {
    this.userInfo = {
      slackId: 'user123',
      channel: 'channel123',
    };

    this.controller = Botmock({
      debug: false,
    });

    this.bot = this.controller.spawn({});

    fileBeingTested(this.controller);
  });

  it('should return correct attachments object in message', () => {
    let sequence = [
      {
        //type: null, //if type null, default to direct_message
        user: this.userInfo.slackId, //user required for each direct message
        channel: this.userInfo.channel, // user channel required for direct message
        messages: [
          {
            text: 'help',
            isAssertion: true,
          }
        ]
      }
    ];

    return this.bot.usersInput(sequence).then((message) => {
      let testValue = {
        attachments: [{
          contentType: "application/vnd.microsoft.card.adaptive",
          content: {
            type: "AdaptiveCard",
            body: [{type: 'TextBlock', text: 'Log Work', size: 'large', weight: 'bolder'}, {
              type: 'TextBlock',
              text: 'You can log work!',
              size: 'normal',
              weight: 'normal',
              separation: 'none',
              wrap: true
            }, {type: 'TextBlock', text: 'Get your time', size: 'large', weight: 'bolder'}, {
              type: 'TextBlock',
              text: 'Time.',
              size: 'normal',
              weight: 'normal',
              separation: 'none',
              wrap: true
            }]
          }
        }]
      };
      return assert.deepEqual(message.attachments, testValue.attachments);
    })
  });
});

Beautiful! I really appreciate all of the work you have put in! I will double check to see if this works upon returning to work :)

Great! It works wonderfully! Do you mind also mapping out for me how I'd go about testing a conversation? So if user says 'What is my name?' then bot should respond 'fbessez, right?' and then I would say 'yes' or 'no'. How do I test that out? Do I add those messages to the sequence? and then add responses?

@fbessez checkout that example please
https://github.com/gratifyguy/botkit-mock/tree/master/examples/convo-bot

authors: amplicity fbessez ihorrusinko

repo: gratifyguy/botkit-mock


text:
Testing Problems

I was making changes trying to fix #4214 and deleted todo_url from 6 places. It was finally working and the tests all passed (except the three that never pass) but then all of a sudden everything failed. I make cleaned et al and now I am having big testing issues.
I stashed my code changes and got my local env is up to date with master and I have rebooted, and make clean/schema/fake a half dozen times. I can make run and the local page works.
When I make pytest it collects 751 items and then hangs on the first test (test_api_key_json.py) if that's relevant.
If I try to make test instead I get:
env/bin/honcho run -e defaults.env,tests/test.env,tests/local.env ./recreate-schema.sh
Recreating public schema ...
and it hangs. @whit537  or anyone... can you help?

What's the current result of git status ?

On branch master
Your branch is up-to-date with 'upstream/master'.
Untracked files:
(use "git add ..." to include in what will be committed)
www/assets/gratipay.css
www/assets/gratipay.js

nothing added to commit but untracked files present (use "git add" to track)

Do you get a postgresql console when you do:
psql gratipay

yes. it says gratipay=#

Hrm, weird! The only thing I can think of:
Switch back to your branch, commit your changes and push them to origin (so you don't lose them) and then blow it up and do a fresh git clone

Just did that. :/ same problem.

Husband just dropped gratipay and gratipay-test databases and reran make schema and it is working now! I have a million errors but this is progress!


text:
[5.5.x] improve clean up logic for failed expand operations

Improve logic for when the expand operation fails or when the agent is explicitly terminated.
Also, provide a set of sub-commands to deal with orphaned operations in a safe manner.

Seems like this will solve part of https://github.com/gravitational/gravity/issues/900 for me :) and perhaps part of https://github.com/gravitational/gravity/issues/897 as well

I had created #1127 but will close as redundant. A customer ran into this issue -
What happened:
For expands, the presence of pending previous expand operations can be a blocker. In order to be able to start a new expand operation, the pending ones need to be removed from the queue (in etcd). Currently, we have been providing customers at times with a script to do so.
What should happen:
There should be a dedicated troubleshooting command to remove errored operations. A potential auto-fix/auto-detect and recover from state would lead to an even more improved user experience.
Example script used:
#!/bin/bash
set -Eeou pipefail
function die {
  >&2 echo $@
  exit 1
}
if [ "$EUID" -ne 0 ]
  then echo "Please run the script as root"
  exit
fi
status=$(gravity status --output=json)
cluster_name=$(echo "${status}" | jq -r ".cluster.domain")
operation_ids=$(echo "${status}" | jq -c -r '.cluster.active_operations[]? | select(.type=="operation_expand") | .id')
if [ "" = "${operation_ids}" ]; then
  die "No active expand operation found"
fi
for id in ${operation_ids}; do
  gravity enter -- --notty /usr/bin/etcdctl -- rm --recursive /gravity/local/sites/${cluster_name}/ops/${id}
done
gravity status-reset

extended debug logging (incl. gRPC logs)
add expiration to controller reconnect loop
attempt to properly fail operation in case of abort (add context HTTP APIs if possible)
(tentative) streaming logs from agent
automatically fail pending operations that do not make progress
complicate logic of operation state transitioning (if join a worker node, cluster can transition to active on error) - same for shrink.

Will this address https://github.com/gravitational/gravity/issues/1036 ?

Partially yes - once the changes are forward-ported to 6.2.x.

Has this been forward ported?

@helgi Yes, the short answer is that it has been. The longer is - the 6.x upwards have diverted from 5.x w.r.t agent handling but the 6.3.x branch has been updated to set the operation to failed upon any error on the side of the joining node to the same effect as 5.x.
There's a small improvement that I need to backport from here - working on it.

Thanks! What about for 7.x?

We're keeping 7.x in sync in any way - so it gets all the same patches.

authors: a-palchikov aelkugia helgi

repo: gravitational/gravity