sfdx force:source:deploy:report is throwing The org cannot be found #1713

jdgirald · 2022-09-14T19:13:49Z

Summary

sfdx force:source:deploy:report sometimes fail with this error: ERROR running force:source:deploy:report: Metadata API request failed: The org cannot be found

This started to happen after we upgrade to version 7.165 from version 7.140

Steps To Reproduce:

run sfdx force:source:deploy:report

System Information

Which shell/terminal are you using? bash

› Warning: sfdx-cli update available from 7.165.0 to 7.166.1.
{
"cliVersion": "sfdx-cli/7.165.0",
"architecture": "linux-x64",
"nodeVersion": "node-v16.17.0",
"pluginVersions": [
"@jayree/sfdx-plugin-manifest 2.2.10 (user)",
"@jayree/sfdx-plugin-prettier 1.1.7 (user)",
"@oclif/plugin-autocomplete 1.3.0 (core)",
"@oclif/plugin-commands 2.2.0 (core)",
"@oclif/plugin-help 5.1.12 (core)",
"@oclif/plugin-not-found 2.3.1 (core)",
"@oclif/plugin-plugins 2.1.0 (core)",
"@oclif/plugin-update 3.0.0 (core)",
"@oclif/plugin-version 1.1.2 (core)",
"@oclif/plugin-warn-if-update-available 2.0.4 (core)",
"@oclif/plugin-which 2.1.0 (core)",
"alias 2.1.0 (core)",
"apex 1.2.0 (core)",
"auth 2.2.3 (core)",
"community 2.0.0 (core)",
"config 1.4.17 (core)",
"custom-metadata 2.0.0 (core)",
"data 2.1.2 (core)",
"generator 2.0.2 (core)",
"info 2.0.1 (core)",
"limits 2.0.1 (core)",
"org 2.2.0 (core)",
"schema 2.1.1 (core)",
"signups 1.2.0 (core)",
"source 2.0.12 (core)",
"telemetry 2.0.0 (core)",
"templates 55.1.0 (core)",
"trust 2.0.3 (core)",
"user 2.1.0 (core)",
"@salesforce/sfdx-plugin-lwc-test 1.0.0 (core)",
"salesforce-alm 54.8.1 (core)",
"sfdx-git-delta 5.0.7 (user)",
"sfdx-jayree 4.3.4 (user)",
"sfpowerkit 5.0.0 (user)"
],
"osVersion": "Linux 5.10.60.1-microsoft-standard-WSL2",
"shell": "bash",
"rootPath": "/usr/local/lib/node_modules/sfdx-cli"
}

Additional information

The text was updated successfully, but these errors were encountered:

github-actions · 2022-09-14T19:14:03Z

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

jverelst · 2022-09-15T09:57:24Z

We are seeing exactly the same, there doesn't seem to be any pattern to this, it makes our deployment pipelines fail from time to time.

stoevie · 2022-09-16T08:56:40Z

We also see the 'org cannot be found error' message since a couple of weeks. We see it with the sfdx force:source:deploy command. sfdx sfdx-cli/7.156.1 (linux) and sfdx-cli/7.167.2 win32-x64.

error: ERROR running force:source:deploy: Metadata API request failed: The org cannot be found

jverelst · 2022-09-16T11:15:38Z

We are now also seeing this on other commands; we use the sfpowerkit plugin to create a pool of scratch orgs and our pipeline throws this error intermittendly:

ERROR running sfpowerkit:pool:create:  Unable to execute command .. Domain Not Found: The org cannot be found

This is on CLI 7.163.0:

{
  "cliVersion": "sfdx-cli/7.163.0",
  "architecture": "linux-x64",
  "nodeVersion": "node-v16.13.1",
  "pluginVersions": [
    "@jayree/sfdx-plugin-legacy 1.1.0 (user)",
    "@jayree/sfdx-plugin-manifest 2.3.0 (user)",
    "@jayree/sfdx-plugin-prettier 1.2.0 (user)",
    "@oclif/plugin-autocomplete 1.3.0 (core)",
    "@oclif/plugin-commands 2.2.0 (core)",
    "@oclif/plugin-help 2.2.3 (user)",
    "@oclif/plugin-not-found 2.3.1 (core)",
    "@oclif/plugin-plugins 2.1.0 (core)",
    "@oclif/plugin-update 3.0.0 (core)",
    "@oclif/plugin-version 1.1.2 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.4 (core)",
    "@oclif/plugin-which 2.1.0 (core)",
    "alias 2.1.0 (core)",
    "apex 1.1.0 (core)",
    "auth 2.2.3 (core)",
    "community 2.0.0 (core)",
    "config 1.4.17 (core)",
    "custom-metadata 2.0.0 (core)",
    "data 2.1.1 (core)",
    "generator 2.0.2 (core)",
    "info 2.0.1 (core)",
    "limits 2.0.1 (core)",
    "org 2.0.7 (core)",
    "schema 2.1.1 (core)",
    "signups 1.2.0 (core)",
    "source 2.0.11 (core)",
    "telemetry 2.0.0 (core)",
    "templates 55.1.0 (core)",
    "trust 2.0.3 (core)",
    "user 2.1.0 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.0 (core)",
    "dxb 1.7.12 (user)",
    "salesforce-alm 54.7.1 (core)",
    "sfdmu 4.15.1 (user)",
    "sfdx-browserforce-plugin 2.9.1 (user)",
    "sfdx-jayree 4.3.18 (user)",
    "sfpowerkit 5.0.0 (user)",
    "texei-sfdx-plugin 1.17.0 (user)"
  ],
  "osVersion": "Linux 5.15.0-1019-azure",
  "shell": "bash",
  "rootPath": "/usr/local/lib/nodejs/lib/node_modules/sfdx-cli"
}

Yurii-Zakharov · 2022-09-23T07:20:16Z

The same issue happens from time to time with command force:mdapi:deploy after upgrade from 7.129.0 to 7.164.2:
ERROR running force:mdapi:deploy: Metadata API request failed: The org cannot be found

jdgirald · 2022-09-28T19:06:54Z

Hi @mshanemc: is this something you can help with? I see this error at least daily in our CI pipeline

cristiand391 · 2022-09-29T20:48:31Z

This error is being thrown from here:

https://github.com/forcedotcom/sfdx-core/blob/main/src/org/connection.ts#L265

When instantiating this class it tries to get the API version to use in requests from a local config value (sfdx config:set apiVersion=55.0 --global) or env var (SFDX_API_VERSION=55.0 sfdx force:org:create -).
If no config value or env var is found, it queries the org to get the max API version available and does a DNS check which is what is failing and makes it throw the "The org cannot be found" error.

Workaround: skip the DNS check by setting SFDX_DISABLE_DNS_CHECK=true or setting the API version using config:set or env var mentioned as mentioned above.

We will require some logs of a deployment without setting the API version to see what URL the dns resolver is getting.

To enable debug mode just set the env var DEBUG to true, e.g.

export DEBUG=true
sfdx force:source:deploy ...

This might be related to this ongoing issue: https://status.salesforce.com/generalmessages/994

jdgirald · 2022-10-03T21:05:22Z

@cristiand391 thanks for the solution. We are not receiving the error anymore.

Should this be documented somewhere? Looks like SFDX_DISABLE_DNS_CHECK optimize the deployment process. There is no point in trying to DNS check every time the metadata API return InProgress while running force:source:deploy:report and the API version is already cached.

Do you think of any issue if we leave this setting true in our pipeline?

bingincap · 2022-10-31T14:41:58Z

Seeing the same problem with sfdx:source:deploy. we run 7.174 on Ubuntu (Github Action). No apparent pattern with when it happens, but it has happened more often recently with multiple sandboxes on different instances (all EU at this point)

slaght · 2022-10-31T20:39:31Z

Multiple projects and environments experiencing this issue. Can someone confirm that SFDX_DISABLE_DNS_CHECK actually exists? It's not listed in the documentation, and doesn't seem to completely fix the issue.

cristiand391 · 2022-11-01T15:25:09Z

@slaght yes, the method that does the dns lookup checks if it's set here:
https://github.com/forcedotcom/sfdx-core/blob/main/src/status/myDomainResolver.ts#L76

If you run SFDX_DISABLE_DNS_CHECK=true DEBUG=* sfdx force:source:deploy:report you should see this message in the log output:
SFDX_DISABLE_DNS_CHECK set to true. Skipping DNS check...

maristei · 2022-11-22T11:47:56Z

Same issue with force:source:deploy (sfdx-cli/7.177.1, GitHub action). Happens sporadically, no apparent pattern.

aheber · 2022-11-22T22:16:59Z

I just got a stack trace on this, waiting for a deployment to complete. Super weird that this is happening during deployment when it has been successfully interacting with this org for an extended time. This one failed 24 minutes into a 60 minute wait timeout.
No reliable pattern but I usually see it a few times a week at a minimum. (probably 5% of runs if I had to guess)

I have not applied the SFDX_DISABLE_DNS_CHECK env var, I'll be doing that later to see if it helps this problem go away.

sfdx force:mdapi:deploy --deploydir distDiff --testlevel RunLocalTests --targetusername [redacted] --wait 60 --json

{
  "result": {
    "id": "[redacted]"
  },
  "status": 1,
  "name": "MetadataTransfer",
  "message": "Metadata API request failed: The org cannot be found",
  "exitCode": 1,
  "context": "Deploy",
  "data": {
    "id": "[redacted]"
  },
  "stack": "MetadataTransferError: Metadata API request failed: The org cannot be found\n    at MetadataApiDeploy.pollStatus (/usr/local/lib/sfdx/node_modules/@salesforce/source-deploy-retrieve/lib/src/client/metadataTransfer.js:83:27)\n    at async Deploy.deploy (/usr/local/lib/sfdx/node_modules/@salesforce/plugin-source/lib/commands/force/mdapi/deploy.js:78:33)\n    at async Deploy.run (/usr/local/lib/sfdx/node_modules/@salesforce/plugin-source/lib/commands/force/mdapi/deploy.js:25:9)\n    at async Deploy._run (/usr/local/lib/sfdx/node_modules/@salesforce/command/lib/sfdxCommand.js:102:40)\n    at async Config.runCommand (/usr/local/lib/sfdx/node_modules/@oclif/core/lib/config/config.js:272:25)\n    at async run (/usr/local/lib/sfdx/node_modules/@oclif/core/lib/main.js:76:5)\nDUE TO:\nDomainNotFoundError: The org cannot be found\n    at Messages.createError (/usr/local/lib/sfdx/node_modules/@salesforce/core/lib/messages.js:446:16)\n    at Connection.isResolvable (/usr/local/lib/sfdx/node_modules/@salesforce/core/lib/org/connection.js:222:28)\n    at async Connection.retrieveMaxApiVersion (/usr/local/lib/sfdx/node_modules/@salesforce/core/lib/org/connection.js:180:9)\n    at async getConnectionNoHigherThanOrgAllows (/usr/local/lib/sfdx/node_modules/@salesforce/source-deploy-retrieve/lib/src/client/metadataTransfer.js:216:27)\n    at async MetadataApiDeploy.checkStatus (/usr/local/lib/sfdx/node_modules/@salesforce/source-deploy-retrieve/lib/src/client/metadataApiDeploy.js:275:28)\n    at async MetadataApiDeploy.poll (/usr/local/lib/sfdx/node_modules/@salesforce/source-deploy-retrieve/lib/src/client/metadataTransfer.js:158:31)\n    at async doPoll (/usr/local/lib/sfdx/node_modules/@salesforce/core/lib/status/pollingClient.js:60:26)",
  "warnings": [],
  "commandName": "Deploy"
}

A little behind on versions:

$ sfdx --version
sfdx-cli/7.173.0 linux-x64 node-v16.17.1
$ sfdx plugins --core
@oclif/plugin-autocomplete 1.3.1 (core)
@oclif/plugin-commands 2.2.0 (core)
@oclif/plugin-help 5.1.14 (core)
@oclif/plugin-not-found 2.3.3 (core)
@oclif/plugin-plugins 2.1.1 (core)
@oclif/plugin-update 3.0.2 (core)
@oclif/plugin-version 1.1.2 (core)
@oclif/plugin-warn-if-update-available 2.0.6 (core)
@oclif/plugin-which 2.1.0 (core)
@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)
alias 2.1.5 (core)
apex 1.3.0 (core)
auth 2.2.14 (core)
community 2.0.7 (core)
config 1.4.21 (core)
custom-metadata 2.0.1 (core)
data 2.1.4 (core)
generator 2.0.6 (core)
info 2.1.10 (core)
limits 2.0.5 (core)
org 2.2.9 (core)
packaging 1.9.4 (core)
salesforce-alm 54.8.1 (core)
schema 2.1.10 (core)
sfdx-cli 7.173.0 (core)
sfdx-devops 0.4.9
sfdx-git-delta 5.5.0
sfdx-heber 0.0.2
shane-sfdx-plugins 4.[43](https://git.doterra.net/development/salesforce/-/jobs/1147686#L43).0
├─ @mshanemc/plugin-streaming 1.1.7
└─ @mshanemc/sfdx-sosl 1.1.0
signups 1.2.7 (core)
source 2.0.19 (core)
telemetry 2.0.2 (core)
templates [55](https://git.doterra.net/development/salesforce/-/jobs/1147686#L55).1.0 (core)
trust 2.0.4 (core)
user 2.1.12 (core)

srinivasan-kr · 2022-11-24T15:33:28Z

We are affected by this too. A complete waste of CI/CD pipeline resources.

joernflath · 2022-11-24T19:06:19Z

Edit 2: It seemed to make it a bit better, but not solved the issue entirely

Edit: with export SFDX_DISABLE_DNS_CHECK=true it now seems to work.

We're experiencing this issue as well:
ERROR running force:source:deploy: Metadata API request failed: The org cannot be found

Tried SFDX_DISABLE_DNS_CHECK=true and setting the API Version and even tried older CLI Versions (7.178.0, 7.175.0, and 7.170). Nothing helped.
Different Salesforce Orgs, same error.

Until three days ago, it only happened occasionally, now it happens almost every time.

ZanePearton · 2022-11-24T21:57:48Z

+1 Impacting CI/CD pipeline.
ERROR running force:source:deploy: Metadata API request failed: The org cannot be found

Inakihu · 2022-11-24T22:06:18Z

Thank you very much @cristiand391 !!!!

Workaround works in my pipeline

npm install sfdx-cli --global
sfdx config:set apiVersion=56.0 --global
export SFDX_DISABLE_DNS_CHECK=true

HerrX2000 · 2022-11-25T13:00:10Z

Still encountering the issue on any of my connected orgs. It is also incredibly frequent for me. From 10 deployments maybe around 2 even start and none can keep the connection till the end. Issue occurs with all source commands: retrieve, deploy, push, pull

I set the recommended vars and running the recommended LTS node version.

JFloresGarcia · 2022-11-25T13:29:25Z

Same here.
I tried everything posted here. I tried changing the version of Salesforce CLI and Node JS to older versions, but nothing works...

bdovh · 2022-11-28T12:38:51Z

I have this error

Inakihu · 2022-11-28T12:48:39Z

Azure Devops Pipelines with Hosted Agent (ubuntu-latest)?

joernflath · 2022-11-28T13:05:06Z

Azure Devops Pipelines with Hosted Agent (ubuntu-latest)?

Yes

cristiand391 · 2022-11-28T13:08:33Z

I'm looking at this, in the screenshot @HerrX2000 posted above I see the err is coming from the deploy library so it might be skipping the env var. Can someone post the full debug of a force:source:push?

JFloresGarcia · 2022-11-28T14:13:56Z

I resolved the problem (at least, for the moment) using older versions from Node JS and Salesforce CLI, 18.12.1 and 7.155.1, and it seems that works, 3 of 3 deployments without errors. I use the SFDX_DISABLE_DNS_CHECK=true but 'm not sure if it do something.

HerrX2000 · 2022-11-28T14:27:09Z

@cristiand391 thanks for pointing out that it might be skipping the env var. Indeed my .bashrc was wrong. It set the var for the bash environment, instead of as global env var. It now works, thank you very much.

Wrong .bashrc:

SFDX_DISABLE_DNS_CHECK=true
export $SFDX_DISABLE_DNS_CHECK

Correct .bashrc line:

export SFDX_DISABLE_DNS_CHECK=true

The export is mandatory, otherwise the variable is not available within the context of sfdx.

git2gus · 2022-11-28T16:32:34Z

This issue has been linked to a new work item: W-12129008

derrick-ejan-rs · 2022-11-28T19:54:18Z

Following. We are also getting the same error and unfortunately I am still getting the same after adding export SFDX_DISABLE_DNS_CHECK=true

ZanePearton · 2022-11-29T07:38:43Z


npm install sfdx-cli --global

sfdx config:set apiVersion=56.0 --global

export SFDX_DISABLE_DNS_CHECK=true

Unfortunately, this doesn't remediate.
Code deploys, however pipelines fails.

HerrX2000 · 2022-11-29T12:14:24Z

To double check if the variable is exported correctly, you can run export | grep SFDX.

@ZanePearton @derrick-ejan-rs

HerrX2000 · 2022-11-29T12:17:13Z

Maybe this helps. My deployment now shows (node:65603) Warning: Network error occurred. Continuing to poll.. Maybe its a symptom of how the deploy library handles short network outages. I am on WIFI, so this could be what caused the DNS check to fail for me.

cristiand391 · 2022-11-29T12:42:57Z

To confirm that the DNS check is being skipped you set the debug env var to only show the logs from the domain resolver, you should see sf:MyDomainResolver DEBUG SFDX_DISABLE_DNS_CHECK set to true. Skipping DNS check... in the logs.

Here's an example running:
DEBUG=sf:MyDomainResolver SFDX_DISABLE_DNS_CHECK=true sfdx force:source:deploy -u easy-spaces --sourcepath es-base-objects/

derrick-ejan-rs · 2022-11-29T18:10:36Z

@cristiand391 thanks that looks like it worked for me.

bdovh · 2022-11-30T12:33:26Z

do you have any fix to Metadata API request failed: The org cannot be found"? This is a blocker for our CI pipelines

bdovh · 2022-11-30T12:34:53Z

shoud we try to use export SFDX_DISABLE_DNS_CHECK=true? Is this an official workaround for this problem?

bdovh · 2022-11-30T12:36:58Z

or is there any different command which works fine, like sfdx force:beta:source:push to have it stable?

cristiand391 · 2022-11-30T12:37:15Z

@bdovh yes, I mentioned it here:
#1713 (comment)

that env var should work for all commands as the domain resolver is the same.

To confirm that the check is being skipped you can enable the debug output, see #1713 (comment)

derrick-ejan-rs · 2022-11-30T14:46:08Z

shoud we try to use export SFDX_DISABLE_DNS_CHECK=true? Is this an official workaround for this problem?

@bdovh yes that is what worked for me. We are using Azure pipelines.

bdovh · 2022-12-01T13:35:55Z

shoud we try to use export SFDX_DISABLE_DNS_CHECK=true? Is this an official workaround for this problem?

@bdovh yes that is what worked for me. We are using Azure pipelines.

I am using Github Action CI pipelines and it still doesn't help. Well, it randomly fails, not every time, but once per two tries

TonyWhiteSMS · 2022-12-02T01:44:10Z

So far this has been working for me in GitHub Actions

      - name: Deploy without test classes
        shell: bash
        env:
          SFDX_DISABLE_DNS_CHECK: true
        run: >-
          sfdx force:source:deploy -x ${{env.PACKAGEXML_FILE}} -u
          ${{env.SF_USERNAME}} -w 10000 --verbose --loglevel fatal

steals · 2022-12-02T07:51:10Z

Still experience issues with network connection during the long deployment. After adding export SFDX_DISABLE_DNS_CHECK=true in the pipeline we don have "The org cannot be found" error, but there is another one

ERROR running force:source:deploy:report: Metadata API request failed: request to ....sandbox.my.salesforce.com/services/Soap/m/56.0 failed, reason: Client network socket disconnected before secure TLS connection was established

bdovh · 2022-12-05T09:22:48Z

So far this has been working for me in GitHub Actions

      - name: Deploy without test classes
        shell: bash
        env:
          SFDX_DISABLE_DNS_CHECK: true
        run: >-
          sfdx force:source:deploy -x ${{env.PACKAGEXML_FILE}} -u
          ${{env.SF_USERNAME}} -w 10000 --verbose --loglevel fatal

let me try that one

khushaldave · 2022-12-05T18:30:54Z

shoud we try to use export SFDX_DISABLE_DNS_CHECK=true? Is this an official workaround for this problem?

@bdovh yes that is what worked for me. We are using Azure pipelines.

I am using Github Action CI pipelines and it still doesn't help. Well, it randomly fails, not every time, but once per two tries

This is what Salesforce support has confirmed as official workaround.

cristiand391 · 2022-12-05T18:36:01Z

FYI: sfdx v7.180.0 (latest-rc) includes a fix for this, see rel notes:
https://github.com/forcedotcom/cli/tree/main/releasenotes/sfdx#71800-dec-8-2022-stable-rc

ERROR running force:source:deploy:report: Metadata API request failed: request to ....sandbox.my.salesforce.com/services/Soap/m/56.0 failed, reason: Client network socket disconnected before secure TLS connection was established

@steals that's a different network error, if you can please open a new GH issue and provide a debug log of the CLI.

nickytorstensson · 2022-12-07T12:13:06Z

Hi @cristiand391
I know it is a stretch question, but based on a lot of the comments above, it seems also to happen for force:source:deploy and not just force:source:deploy:report.

Do you know if the fix will also apply to force:source:deploy?

cristiand391 · 2022-12-07T12:23:23Z

@nickytorstensson the fix was done on the sfdx-core library: forcedotcom/sfdx-core#712

The fix should apply to all commands that interact with an org as the connections to it are done using sfdx-core.

As I mentioned in the comment below, the fix is included in the current release candidate, not in latest stable (the one most people use).
See: https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli_rc.htm

If you are still getting the The org cannot be found err with sfdx >= v7.180.0, please let us know.

cromwellryan · 2022-12-08T15:16:09Z

🚀 sfdx 7.180.0 is now stable/GA with fixes for this issue. If you had been holding off installing during the RC period, you can now upgrade!

bdovh · 2022-12-09T09:57:19Z

@nickytorstensson the fix was done on the sfdx-core library: forcedotcom/sfdx-core#712

The fix should apply to all commands that interact with an org as the connections to it are done using sfdx-core.

As I mentioned in the comment below, the fix is included in the current release candidate, not in latest stable (the one most people use). See: https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli_rc.htm

If you are still getting the The org cannot be found err with sfdx >= v7.180.0, please let us know.

I have a question, does it fix also the sfdx force:source:push command?

RodEsp · 2022-12-09T17:09:59Z

@bdovh yes, it should.

bdovh · 2022-12-12T08:51:32Z

is 7.180 GA?

Why when I try to execute the script

node --version
npm install sfdx-cli --global
export SFDX_DISABLE_DNS_CHECK=true
echo "Version of SFDX CLI is: $(sfdx --version)"

it installs the version

Version of SFDX CLI is: sfdx-cli/7.179.0 linux-x64 node-v16.18.1

cristiand391 · 2022-12-12T12:35:44Z

@bdovh yes, you can see the latest tag points to 7.180.0:

➜  sf-plugin-api git:(cd/cleanup) ✗ npm show sfdx-cli dist-tags
{
  latest: '7.180.0',
  'latest-rc': '7.181.1',
  dev: '7.177.0-dev.4',
  'dev-rc': '7.177.0-dev.4'
}

jdgirald added the investigating We're actively investigating this issue label Sep 14, 2022

shetzel added bug Issue or pull request that identifies or fixes a bug and removed investigating We're actively investigating this issue labels Nov 28, 2022

shetzel mentioned this issue Nov 30, 2022

Sh/connection perf forcedotcom/sfdx-core#712

Merged

RodEsp closed this as completed Dec 9, 2022

estebanefi mentioned this issue Jan 23, 2023

SFDX Update to 7.180 from 7.179 dxatscale/sfpowerscripts#1201

Closed

sfdx force:source:deploy:report is throwing The org cannot be found #1713

sfdx force:source:deploy:report is throwing The org cannot be found #1713

Comments

jdgirald commented Sep 14, 2022

Summary

Steps To Reproduce:

System Information

Additional information

github-actions bot commented Sep 14, 2022

jverelst commented Sep 15, 2022

stoevie commented Sep 16, 2022 • edited Loading

jverelst commented Sep 16, 2022

Yurii-Zakharov commented Sep 23, 2022

jdgirald commented Sep 28, 2022

cristiand391 commented Sep 29, 2022 • edited Loading

jdgirald commented Oct 3, 2022

bingincap commented Oct 31, 2022

slaght commented Oct 31, 2022

cristiand391 commented Nov 1, 2022

maristei commented Nov 22, 2022

aheber commented Nov 22, 2022

srinivasan-kr commented Nov 24, 2022 • edited Loading

joernflath commented Nov 24, 2022 • edited Loading

ZanePearton commented Nov 24, 2022 • edited Loading

Inakihu commented Nov 24, 2022

HerrX2000 commented Nov 25, 2022 • edited Loading

JFloresGarcia commented Nov 25, 2022

bdovh commented Nov 28, 2022

Inakihu commented Nov 28, 2022

joernflath commented Nov 28, 2022

cristiand391 commented Nov 28, 2022

JFloresGarcia commented Nov 28, 2022

HerrX2000 commented Nov 28, 2022 • edited Loading

git2gus bot commented Nov 28, 2022

derrick-ejan-rs commented Nov 28, 2022

ZanePearton commented Nov 29, 2022

HerrX2000 commented Nov 29, 2022

HerrX2000 commented Nov 29, 2022

cristiand391 commented Nov 29, 2022

derrick-ejan-rs commented Nov 29, 2022

bdovh commented Nov 30, 2022

bdovh commented Nov 30, 2022

bdovh commented Nov 30, 2022

cristiand391 commented Nov 30, 2022 • edited Loading

derrick-ejan-rs commented Nov 30, 2022

bdovh commented Dec 1, 2022

TonyWhiteSMS commented Dec 2, 2022

steals commented Dec 2, 2022 • edited Loading

bdovh commented Dec 5, 2022

khushaldave commented Dec 5, 2022

cristiand391 commented Dec 5, 2022

nickytorstensson commented Dec 7, 2022

cristiand391 commented Dec 7, 2022 • edited Loading

cromwellryan commented Dec 8, 2022 • edited Loading

bdovh commented Dec 9, 2022

RodEsp commented Dec 9, 2022

bdovh commented Dec 12, 2022

cristiand391 commented Dec 12, 2022

stoevie commented Sep 16, 2022 •

edited

Loading

cristiand391 commented Sep 29, 2022 •

edited

Loading

srinivasan-kr commented Nov 24, 2022 •

edited

Loading

joernflath commented Nov 24, 2022 •

edited

Loading

ZanePearton commented Nov 24, 2022 •

edited

Loading

HerrX2000 commented Nov 25, 2022 •

edited

Loading

HerrX2000 commented Nov 28, 2022 •

edited

Loading

cristiand391 commented Nov 30, 2022 •

edited

Loading

steals commented Dec 2, 2022 •

edited

Loading

cristiand391 commented Dec 7, 2022 •

edited

Loading

cromwellryan commented Dec 8, 2022 •

edited

Loading