Deploy the app to Twilio fails

Hi Guys,
Am trying to install on my local Dev which is macOS 10.13. This command fails:
$ npm run deploy:twilio-cli
Details below...
Kind Regards
Trent
Issue Summary
The deploy step from the 'how to...' is not working. I had some problems with some file permissions with the 'node_modules' directory but have been able to fix that. Now I've gotten to the end step and it still throws the same error:
» twilio-cli encountered an unexpected error. To report this issue, execute the command with the "-l debug" flag, then copy the output to a new issue here: https://github.com/twilio/twilio-cli/issues
How do I add the "-l debug" flag to the npm command? It throws an error as well.
Steps to Reproduce
Install Twilio CLI
Install the RTC plugin
$ npm run deploy:twilio-cli
Exception/Log
paste exception/log here
0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   '/usr/local/bin/node',
1 verbose cli   '/usr/local/bin/npm',
1 verbose cli   'run',
1 verbose cli   'deploy:twilio-cli'
1 verbose cli ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [
4 verbose run-script   'predeploy:twilio-cli',
4 verbose run-script   'deploy:twilio-cli',
4 verbose run-script   'postdeploy:twilio-cli'
4 verbose run-script ]
5 info lifecycle twilio-video-app-react@0.1.0~predeploy:twilio-cli<EMAIL_ADDRESS>6 info lifecycle twilio-video-app-react@0.1.0~deploy:twilio-cli<EMAIL_ADDRESS>7 verbose lifecycle twilio-video-app-react@0.1.0~deploy:twilio-cli: unsafe-perm in lifecycle true
8 verbose lifecycle twilio-video-app-react@0.1.0~deploy:twilio-cli: PATH: /usr/local/lib/node_modu$
9 verbose lifecycle twilio-video-app-react@0.1.0~deploy:twilio-cli: CWD: /Users/trentadamson/Sites$
10 silly lifecycle twilio-video-app-react@0.1.0~deploy:twilio-cli: Args: [
10 silly lifecycle   '-c',
10 silly lifecycle   'cross-env REACT_APP_SET_AUTH=passcode npm run build && twilio rtc:apps:video$
10 silly lifecycle ]
11 silly lifecycle twilio-video-app-react@0.1.0~deploy:twilio-cli: Returned: code: 1  signal: null
12 info lifecycle twilio-video-app-react@0.1.0~deploy:twilio-cli: Failed to exec deploy:twilio-cli$
13 verbose stack Error<EMAIL_ADDRESS>deploy:twilio-cli: cross-env REACT_APP_SET_A$ 13 verbose stack Exit status 1 13 verbose stack     at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm$ 13 verbose stack     at EventEmitter.emit (events.js:310:20) 13 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm$ 13 verbose stack     at ChildProcess.emit (events.js:310:20) 13 verbose stack     at maybeClose (internal/child_process.js:1021:16) 13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5) 14 verbose pkgid<EMAIL_ADDRESS>15 verbose cwd /Users/trentadamson/Sites/twilio-video-app-react 16 verbose Darwin 17.7.0 17 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "deploy:twilio-cli" 18 verbose node v12.16.2 19 verbose npm  v6.14.4 20 error code ELIFECYCLE 21 error errno 1 22 error<EMAIL_ADDRESS>deploy:twilio-cli: cross-env REACT_APP_SET_AUTH=passcode np$
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>deploy:twilio-cli script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]
Technical details:

twilio-cli version:
node version:
Command output with debug logging enabled (adding -l debug to the end of the command):

Thanks for the issue @wotmed!
To use -l debug with npm, you'll need to add an extra --.  Like this:
npm run deploy:twilio-cli -- -l debug
Please try that and let me know if you see anything useful in the logs.  Thanks!

Thanks @timmydozza! worked a treat! I guess we learn something new everyday :-/
Here's the full log. It's having a problem reading a 'sid'. Would that be the Account Sid, maybe?
Creating an optimized production build...
Compiled successfully.
File sizes after gzip:
262.89 KB  build/static/js/2.061e261a.chunk.js
13.29 KB   build/static/js/main.8dddee37.chunk.js
784 B      build/static/js/runtime-main.fa60846a.js
[DEBUG] Config File: /Users/trentadamson/.twilio-cli/config.json
[DEBUG] Using profile: trentada
[DEBUG] -- BEGIN Twilio API Request --
[DEBUG] GET https://serverless.twilio.com/v1/Services
[DEBUG] User-Agent: @twilio/cli-core/4.6.0 (twilio-node/3.42.2, node.js v12.16.2, darwin 17.7.0 x64, rtc:apps:video:deploy)
[DEBUG] -- END Twilio API Request --
[DEBUG] response.statusCode: 200
[DEBUG] response.headers: {"date":"Tue, 28 Apr 2020 00:03:45 GMT","content-type":"application/json; charset=utf-8; charset=utf-8","content-length":"1067","connection":"close","twilio-concurrent-requests":"1","twilio-request-id":"RQbb9ab2765c684aac8727caf1b614fc18","twilio-request-duration":"0.039","access-control-allow-origin":"","access-control-allow-headers":"Accept, Authorization, Content-Type, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since","access-control-allow-methods":"GET, POST, DELETE, OPTIONS","access-control-expose-headers":"ETag","access-control-allow-credentials":"true","x-powered-by":"AT-5000","x-shenanigans":"none","x-home-region":"us1","x-api-domain":"serverless.twilio.com","strict-transport-security":"max-age=31536000"}
[DEBUG] -- BEGIN Twilio API Request --
[DEBUG] GET https://serverless.twilio.com/v1/Services/ZSe288b8aaf2c30802504f9b5506fa0486/Environments
[DEBUG] User-Agent: @twilio/cli-core/4.6.0 (twilio-node/3.42.2, node.js v12.16.2, darwin 17.7.0 x64, rtc:apps:video:deploy)
[DEBUG] -- END Twilio API Request --
[DEBUG] response.statusCode: 200
[DEBUG] response.headers: {"date":"Tue, 28 Apr 2020 00:03:46 GMT","content-type":"application/json; charset=utf-8; charset=utf-8","content-length":"380","connection":"close","twilio-concurrent-requests":"1","twilio-request-id":"RQ8242f5e642ce4fab8b1be08f02973221","twilio-request-duration":"0.018","access-control-allow-origin":"","access-control-allow-headers":"Accept, Authorization, Content-Type, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since","access-control-allow-methods":"GET, POST, DELETE, OPTIONS","access-control-expose-headers":"ETag","access-control-allow-credentials":"true","x-powered-by":"AT-5000","x-shenanigans":"none","x-home-region":"us1","x-api-domain":"serverless.twilio.com","strict-transport-security":"max-age=31536000"}
» twilio-cli encountered an unexpected error. To report this issue, execute the command with the "-l debug" flag, then copy the output to a new issue here: https://github.com/twilio/twilio-cli/issues
[DEBUG] Cannot read property 'sid' of undefined
[DEBUG] TypeError: Cannot read property 'sid' of undefined
at DeployCommand.getAppInfo (/Users/trentadamson/.twilio-cli/node_modules/@twilio-labs/plugin-rtc/src/helpers.js:76:64)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async DeployCommand.run (/Users/trentadamson/.twilio-cli/node_modules/@twilio-labs/plugin-rtc/src/commands/rtc/apps/video/deploy.js:18:20)
at async DeployCommand._run (/Users/trentadamson/.twilio-cli/node_modules/@oclif/command/lib/command.js:42:20)
at async Config.runCommand (/usr/local/lib/node_modules/twilio-cli/node_modules/@oclif/config/lib/config.js:172:9)
at async Main.run (/usr/local/lib/node_modules/twilio-cli/node_modules/@oclif/command/lib/main.js:21:9)
at async Main._run (/usr/local/lib/node_modules/twilio-cli/node_modules/@oclif/command/lib/command.js:44:20)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>deploy:twilio-cli: cross-env REACT_APP_SET_AUTH=passcode npm run build && twilio rtc:apps:video:deploy --authentication=passcode --app-directory ./build "-l" "debug"
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>deploy:twilio-cli script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR!      /Users/trentadamson/.npm/_logs/2020-04-28T00_03_46_984Z-debug.log

Hey @wotmed
I recommend trying these suggested steps. I believe @timmydoza  fixed and mitigated this problem in the latest version of the plugin. Please try the steps and let us know. I'll close the issue for now, but reopen if you continue to experience this problem.
Thanks!


Explicitly numbered replacement fields for maintainability

…ility

Thanks @proinsias, merged.

It would be helpful if for future PRs you would describe in a little more detail what the issue was. Here, it took me a while to figure out that while {} is actually more (not less) maintainable than {0}, it is invalid syntax in Python 2.6 and hence should be removed.


Url in Text sent with Adaptive Card Carousel not clickable

Next to #4539 we have also found that URL's in the Text sent with an adaptive card carousel are rendered but not clickable on the Teams Desktop client.
It renders like a URL and seems to be clickable but it is not (it is working fine on Android, IOS the text doesn’t appear (original issue) so not possible to check this yet). When clicking on the URL nothing happens.
Any url like this in the text field if also sending a adaptive card carousel:
[url text](https://google.com)
As a temporary workaround we’ve just changed to send two messages at once, first the text, then the carousel adaptive card. That way it works fine on all clients (text visible and url clickable).

@JordyGit - We are able to repro this issue.

We have raised a bug and the concerned team is looking into it.

@JordyGit can you share card payload? I use my own bot to test a simple carousel of 2 adaptive cards containing [url text](https://google.com) as TextBlock, but I can not repro this issue.

Hi, the card payload doesn’t make any difference. It’s the text put in the activity next to the attachments.
Activity contains:
-> Text
-> Attachments
-> …
The attachment is the carousel of adaptive cards which works perfectly. But the text displayed above the carousel (not displayed on IOS, that is the other tagged issue) displays the URL, but it is not clickable.
Is this explanation more clear?

@JordyGit This is the payload I tested and it works perfect for me (as below). Can you share yours?
{
  "attachmentLayout": "carousel",
  "attachments": [
    {
      "contentType": "application/vnd.microsoft.card.adaptive",
      "content": {
        "body": [
          {
            "type": "TextBlock",
            "text": "[url text](https://google.com)"
          }
        ]
      }
    },
    {
      "contentType": "application/vnd.microsoft.card.adaptive",
      "content": {
        "body": [
          {
            "type": "TextBlock",
            "text": "[url text](https://google.com)"
          }
        ]
      }
    }
  ]
}

Yes because that Text is in the adaptive card. I am trying to tell you the text should be next to (above) the attachments.
See in the next example a message json I copied from the Bot Emulator which includes the text and attachement.
The Text contains the url, the content of the carousel attachment doesn't matter, the Url is never clickable.
{     "type": "message",     "serviceUrl": "https://9e7a-194-78-124-243.ngrok.io",     "channelId": "emulator",     "from": {         "id": "b6c63a20-406d-11ec-815d-ad41c66a9f38",         "name": "Bot",         "role": "bot"     },     "conversation": {         "id": "a64eb4f0-415e-11ec-815d-ad41c66a9f38|livechat"     },     "recipient": {         "id": "d8584435-23d4-4c41-acfb-c29a45d49fcd",         "role": "user"     },     "attachmentLayout": "carousel",     "locale": "en-US",     "text": "I've listed the first 10 found elements below. Try to be more specific or view all your elements with [Remote Access](https://escape-bot.local.dataminer.services:3001/monitoring/view/-1/elements).",     "inputHint": "acceptingInput",     "attachments": [         {             "contentType": "application/vnd.microsoft.card.adaptive",             "content": {                 "type": "AdaptiveCard",                 "body": [                     {                         "type": "TextBlock",                         "size": "Medium",                         "weight": "Bolder",                         "text": "Element AMS_IRD02"                     },                     {                         "type": "TextBlock",                         "spacing": "None",                         "text": "The element is Active.",                         "isSubtle": true,                         "wrap": true                     },                     {                         "type": "FactSet",                         "facts": [                             {                                 "title": "Alarm Level:",                                 "value": "Major"                             },                             {                                 "title": "Alarms:",                                 "value": "1"                             }                         ]                     }                 ],                 "actions": [                     {                         "type": "Action.OpenUrl",                         "title": "Open",                         "url": "https://escape-bot.local.dataminer.services:3001/monitoring/element/3/1"                     },                     {                         "type": "Action.Submit",                         "title": "Alarms",                         "data": {                             "CustomActionId": "GetAlarmsForElementId",                             "ElementId": "1",                             "DataMinerId": "3",                             "ElementName": "AMS_IRD02"                         }                     }                 ],                 "msteams": {                     "width": "Full"                 },                 "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",                 "version": "1.2"             }         },         {             "contentType": "application/vnd.microsoft.card.adaptive",             "content": {                 "type": "AdaptiveCard",                 "body": [                     {                         "type": "TextBlock",                         "size": "Medium",                         "weight": "Bolder",                         "text": "Element TOR-6 Uplink Power Control"                     },                     {                         "type": "TextBlock",                         "spacing": "None",                         "text": "The element is Paused.",                         "isSubtle": true,                         "wrap": true                     },                     {                         "type": "FactSet",                         "facts": [                             {                                 "title": "Alarm Level:",                                 "value": "Normal"                             },                             {                                 "title": "Alarms:",                                 "value": "10"                             }                         ]                     }                 ],                 "actions": [                     {                         "type": "Action.OpenUrl",                         "title": "Open",                         "url": "https://escape-bot.local.dataminer.services:3001/monitoring/element/3/10"                     },                     {                         "type": "Action.Submit",                         "title": "Alarms",                         "data": {                             "CustomActionId": "GetAlarmsForElementId",                             "ElementId": "10",                             "DataMinerId": "3",                             "ElementName": "TOR-6 Uplink Power Control"                         }                     }                 ],                 "msteams": {                     "width": "Full"                 },                 "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",                 "version": "1.2"             }         }     ],     "entities": [],     "replyToId": "d0cb0f70-415f-11ec-9ca9-67404865d900",     "id": "d40a5bf0-415f-11ec-9ca9-67404865d900",     "localTimestamp": "2021-11-09T14:20:37+01:00",     "timestamp": "2021-11-09T13:20:37.679Z" }

@robin-liao Do you understand the example/issue?

@JordyGit - The issue is currently fixed and merged. We will update you once it gets rolled out publicly. Thanks!

@JordyGit - We checked the issue in Microsoft Teams Version <IP_ADDRESS>564 (64-bit). It was last updated on 07-01-2022 and it seems to be fixed. Please do verify by updating your Microsoft Teams desktop version.

As long as issue https://github.com/MicrosoftDocs/msteams-docs/issues/4539 is not fixed, we won't remove the workaround in our app/bot. Only then we'll check if this all got resolved.


Can not use BitBucket Discovery with non-standard TCP port

Expected Behavior
I expect to be able to utilize BitBucket discovery with a server listening on something other than port 80 or 443, with a config file like so:
integrations:
  bitbucket:
    - host: localhost:8081
      username: my_user
      token: some_token
      apiBaseUrl: http://localhost:8081/rest/api/1.0

catalog:
  rules:
    - allow: [Component, System, API, Group, User, Template, Location]
  locations:
    - type: bitbucket-discovery
      target: http://localhost:8081/projects/foo/repos/*/catalog-info.yaml

Current Behavior
BB discovery throws the following warning at app startup:
2021-08-13T19:05:35.370Z catalog warn Processor BitbucketDiscoveryProcessor threw an error while reading bitbucket-discovery:http://localhost:8081/projects/foo/repos/*/catalog-info.yaml; caused by Error:
 There is no Bitbucket integration that matches http://localhost:8081/projects/foo/repos/*/catalog-info.yaml. Please add a configuration entry for it under integrations.bitbucket type=plugin

Possible Solution
Replace parsed.hostname with parsed.host in basicIntegrations.byUrl()
Steps to Reproduce
Reproducing requires starting up a BB server on a non-standard port and is probably more trouble than it's worth. Instead, it's easier to look at why parsed.hostname is a bug:
const parsed = new URL("http://localhost:8081/rest/api/1.0");
console.log(`Host: ${parsed.host}`); // localhost:8081
console.log(`Hostname: ${parsed.hostname}`); // localhost

Your Environment

Verified on Linux NodeJS v10.19.0 and Windows NodeJS v14.17.4

Makes sense! Is this something you might want to contribute?
For extra points, I guess one might consider being extra thorough by seeing that https://x is the same as https://x:443 etc.

Uh... Easier said than done. I'm at a client not too thrilled at the idea of contributing to OSS. I figure this issue skating right on the edge 😂

@DavidZemon Does it look like this might address this hypothetical problem, if some hypothetical user might have run into it? :) https://github.com/backstage/backstage/pull/6927

It's all so abstract and hard to tell... But hypothetically, it just might! Thanks!


Bump babel to 7.9.1

7.9.0 changelog
7.9.1 changelog

Mostly interested in bugfixes for preset-env. Will enable after first size diff.

Increases are from 1B per component and RootRef being a class component. This is just a legacy component so I'm not fighting for 400B.


use the new LineageEvent instead of LineageReceived

see https://github.com/BuddhistDigitalResourceCenter/owl-schema/commit/28ec849765638d5af77ee0b6f93422926ab0c75d

the type is not explicit in the migrated data so no need for a change here


Settings on double click from systray 2 comes up

double click on systray, 2 comes up

only should have one window.  (and no white box also :))


Variant human created in DnDBeyond is imported to Foundry and adding Mark of Passage when it shouldn't

Describe the bug
My player create a Forgotten Realms character on DnDBeyond and even though I made sure that "Eberron Content" is not selected there, when I import the PC into Foundary, it adds the Mark of Passage to the character in Foundry (Forge).  This is a Forgotten Realms campaign and that's not allowable. Additionally, I disallowed "Favorite Foe" but the importer set it even though it's not on the DnDBeyond character sheet. The DnDBeyond sheed has "Favorite Enemy" as it should.
To Reproduce
Steps to reproduce the behavior:

Create a brand new actor in Foundry.
Click on the DnDBeyond button on the actor.
Import the following PC: https://www.dndbeyond.com/characters/76571906
Start the import (I'll attach configuration screens)

Expected behavior
The Mark of Passage traits should not be added.
Screenshots
The process I step through:

The configuration:

The result:

Environment:

Version 116.0.5845.187 (Official Build) (64-bit)
Foundry Version [10.303]
5e System Version [e.g 2.3.1]
Module Version [e.g 3.4.66]
Does this behaviour occur with other modules disabled: Yes/No (Really not sure. I started pretty vanilla and slowly added modules but this HAS been a problem)

Additional context
Add any other context about the problem here.
None

It's adding these because these are custom actions that have been added to the character on DDB, if you don't want them imported, don't add them to the character on DDB.

Thanks. The player must've added them. I've removed them.


crypto.pbkdf2Sync - ~40% performance drop from node 14/16 to 18/20

Version
v18.16.0
Platform
Microsoft Windows NT 10.0.19045.0 x64
Subsystem
crypto
What steps will reproduce the bug?
const crypto = require('crypto');
const ts = Date.now();
crypto.pbkdf2Sync('XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX', 'XXXXXXXXXXXXXXXXXXXXXXXXXXX', 100000, 32, 'sha512');
console.log(Date.now() - ts);

How often does it reproduce? Is there a required condition?
The code snippet in varying platforms logs lower numbers when ran on Node.js 14 & 16 (better) comparatively to Node.js 18 & 20 (worse).
Examples:
Windows 10

node 14/16: 70
node 18/20: 99

Ubuntu 20

node 14/16: 177
node 18/20: 240

And I've encountered similar results on Ubuntu 22, Debian 11, etc...
What is the expected behavior? Why is that the expected behavior?
I would expect no performance regression.
What do you see instead?
Performance regression ranging from ~30% to ~40%
Additional information
No response

Probably related to #72

Built Node.js 18 from source with OpenSSL 1.1.1t on the Ubuntu 20 system - the build took some hours.
$ node poc.js
162
$ node poc.js
160

At least there is a workaround now. Thanks for the info!


Turn the about popup into an about view

Turn the about popup into an about view that we'll be able to put more stuff into.

Version number
Contributors
Open Source Licences
Send your feedback
Rate the app

It was killed a while ago. We added most of that to the settings.


Simplify manual running of interop tests

Fixes https://github.com/grpc/grpc/issues/10016
Added --manual_run option to run_interop_tests.py with the following behavior:

builds all necessary interop docker images and leaves them around for later use (attention, they can accumulate over time)
skips running tests, but generates interop_server_cmds.sh and interop_client_cmds.sh files with a massages version of docker commands that can be used to actually run the interop tests.

Sample output:
$ tools/run_tests/run_interop_tests.py -l java -s csharp --use_docker --manual_run
Seen --use_docker flag, will run interop tests under docker.

IMPORTANT: The changes you are testing need to be locally committed
because only the committed changes in the current branch will be
copied to the docker environment.
START: Building interop docker images.
PASSED: build_docker_java [time=31.3sec; retries=0:0]
PASSED: build_docker_csharp [time=58.8sec; retries=0:0]
SUCCESS: All docker images built successfully.
All tests will skipped --manual_run option is active.
SKIPPED: cloud_to_cloud:java:csharp_server:large_unary
SKIPPED: cloud_to_cloud:java:csharp_server:empty_unary
SKIPPED: cloud_to_cloud:java:csharp_server:ping_pong
SKIPPED: cloud_to_cloud:java:csharp_server:empty_stream
SKIPPED: cloud_to_cloud:java:csharp_server:client_streaming
SKIPPED: cloud_to_cloud:java:csharp_server:server_streaming
SKIPPED: cloud_to_cloud:java:csharp_server:cancel_after_begin
SKIPPED: cloud_to_cloud:java:csharp_server:cancel_after_first_response
SKIPPED: cloud_to_cloud:java:csharp_server:timeout_on_sleeping_server
SKIPPED: cloud_to_cloud:java:csharp_server:custom_metadata
SKIPPED: cloud_to_cloud:java:csharp_server:status_code_and_message
SKIPPED: cloud_to_cloud:java:csharp_server:unimplemented_method
SKIPPED: cloud_to_cloud:java:csharp_server:unimplemented_service
SUCCESS: All tests passed
Command log written to file interop_server_cmds.sh
Command log written to file interop_client_cmds.sh
Preserving docker image: grpc_interop_java:6de83e66-7793-41d8-a13a-367a92ad1ec0
Preserving docker image: grpc_interop_csharp:5bbeb172-8c74-41ba-a263-55a07e0174dc

Btw, to run cloud_to_cloud tests manually (when using a local docker server), one needs to first check which port is exposed by the server docker.
docker port YOUR_SERVER_CONTAINER 8080

CC @yongni - this change should have most of the features you need to setup docker testing against older releases.  So technically this supersedes most of #9916.

CC @ejona86 @ctiller  @dgquintas  @matt-kwong  @nicolasnoble

How do I find "YOUR_SERVER_CONTAINER", such as "grpc_interop_csharp:5bbeb172-8c74-41ba-a263-55a07e0174dc" in your example?

@adelez  the "YOUR_SERVER_CONTAINER" will be printed when the script runs:
Preserving docker image: grpc_interop_java:6de83e66-7793-41d8-a13a-367a92ad1ec0
Preserving docker image: grpc_interop_csharp:5bbeb172-8c74-41ba-a263-55a07e0174dc

For manual use, that should be fine. In the future, we might also save the list to a file as @yongni  suggested.

Known failures:
https://github.com/grpc/grpc/issues/9804
https://github.com/grpc/grpc/issues/9399


Rework quickstarter concept

To consolidate existing issues, I'm creating a new issue here.
We want to redo the quickstarter concept. So far, the following goals have been distilled:

Replace Rundeck with (Jenkins) pipelines. This reduces the number of used software, and Rundeck was always a pain (separate install, difficult to keep in sync with Github, difficult to understand and change). This has been suggested in https://github.com/opendevstack/ods-project-quickstarters/issues/68#issuecomment-474296795.

Allow multiple quickstarter repos. The main use-case for this is to have a "private" repo only in BitBucket, and a public one in GitHub. However, it does not need to be limited to those

More flexibility within the quickstarters. Right now they assume that everything has the same OpenShift resources etc.

Testable quickstarters. Probably the most important requirement - we finally need CI for quickstarters to make them less brittle

Contributing to quickstarters should be easy. Right now it is difficult to understand where to make changes, and it is very hard to experiment and test the changes made

Proper templating. So far we use sed to replace strings, we should have a proper templating language to render e.g. Jenkinsfile and sonar-project.properties.

"Common interface" to each quickstarter. E.g. a Makefile with standardized targets like build, image, deploy, test etc ... That way all QS can be interacted with in a standard fashion, which should enable orchestration of releases of multiple repos ...

(Potentially) handle common dependencies of quickstarters (e.g. build images, slaves, ...). Right now each quickstarter assumes that e.g. the Jenkins slave magically exists. If we want to have a dynamic number of quickstarte (repos), we probably need some "register"/"install" function to make sure a quickstarter can be used

(Potentially) allow to pass options to quickstartes when provisioning them, see #211.

Move quickstarter-unrelated things to ods-core, see #1, #2, #3

Do not store OCP templates in OpenShift, but rather use the files in the repo to apply them with Tailor. See #38.

Deliver OpenShift templates/config with the created repository (and do not create the OCP resources while provisioning, but as a step in the Jenkins pipeline). See #60.

FYI @clemensutschig @hugowschneider @metmajer @rattermeyer @henrjk @stitakis Please review those goals and let me know if you agree on those as (preliminary) scope for 2.0

Regarding

Testable quickstarters. Probably the most important requirement - we finally need CI for quickstarters to make them less brittle

The way one can currently tests a new quickstarter from the provision app manually is way too painful. Some of the issues were described in this comment.  I would want to be able to also make manual testing much easier. Perhaps simply by telling the Provisioning app where to find the quickstarter. Of course CI/CD is also needed so that refactorings don't break existing quickstarters.
So I see several testing requirements:

Testable quickstarters. Make it easy to test quickstarters under development end to end.
Have CI/CD  in place to:

validates that ods owned quickstarters are not broken
so that external quickstarters are not broken unintended.

I would like to bring a different view on quickstarter provisioning into the discussion: as a developer, I'd love to be able to just go into a directory and do the following to handle the bootstrapping of a quickstarter into my project.
ods project $MY_PROJECT
ods quickstarter new <name> --type=java

Where MY_PROJECT is a name that references a project in BitBucket and the quickstarter's name argument references the variable name part of a repository inside this project. (Technically speaking, the CLI would reference a (Go?) library that implements the provisioning process.) This indirection to our current way of provisioning would provide the following benefits:

paves the way for arbitrary project structures and mono-repos (we could get rid of the restriction of 1 quickstarter = 1 Repo)
allows CLI, REST API and Web UI to be thin layers on top of a central and teste library
easily integrates into anything scripted, e.g., from pipelines to live demos
subsequently opens up the provisioner to support custom-built quickstarters (if we support a --url next to  --type), so that teams do not depend on upstream quickstarters alone

As an additional point, and in line with 9), it would be beneficial to support arbitrary branching strategies to be configured into the quickstarter. Why? Because the branching strategy is a reflection of how developers manage code and we shouldn't expect everyone to be comfortable with Gitflow.

Also, I would like to see documentation vastly improved and build community content that allows users of ODS to get started quickly.

@metmajer Regarding "branching strategy": quickstarters do not dictate gitflow right now, in fact it isn't even the default. Developers are free to come up with their own branch-to-environment mapping in the Jenkinsfile (see https://github.com/opendevstack/ods-jenkins-shared-library/blob/master/README.md#workflow). Does the current solution sound fine to you or would you want sth else?
Also, I really really like the CLI idea! However, I see two major downsides of running a CLI locally:

We need to create a webhook in BitBucket, to enable automatic builds on push. Doing this via the CLI requires the user to authenticate to BitBucket
Right now, the dependencies required for each quickstarter to create the source files are located in the base-slaves used by Rundeck. If the CLI runs locally, each user needs to have the dependencies installed locally. This sounds both more cumbersome and more brittle then the current approach.

I have not found a satisfying answer to those two problems, but maybe you have ideas? I'd love to have what you describe :)

paves the way for arbitrary project structures and mono-repos (we could get rid of the restriction of 1 quickstarter = 1 Repo)

@metmajer What do you mean with arbitrary project structures?
Just to mention it. It was and as far as I know it still a core paradigm of the ODS that the setup for a project defined by a quickstarter is unified to satisfy business, compliance and security needs out-of-the-box and to ease developer transisitions between projects.
Depending on how arbitrary project structure is meant, it contradicts the paradigm.
And just another question:
Which restriction do you mean? Do you mean, the current restriction, that there is only one quicktarter repo defined?
I like the idea of a CLI implementation, we should discuss this in the open office hours.

Whatever we go for seed to be NOT Lust Developer centric but easy to use as
the prov App todayeuch enables 100+ users every day..  One repo One
component makes also defaulting over configuration very real...
Torsten Jaeschke<EMAIL_ADDRESS>schrieb am Fr., 28. Juni 2019,
21:26:

paves the way for arbitrary project structures and mono-repos (we
could get rid of the restriction of 1 quickstarter = 1 Repo)

@metmajer https://github.com/metmajer What do you mean with arbitrary
project structures?
Just to mention it. It was and as far as I know it still a core paradigm
of the ODS that the setup for a project defined by a quickstarter is
unified to satisfy business, compliance and security needs out-of-the-box
and to ease developer transisitions between projects.
Depending on how arbitrary project structure is meant, it contradicts the
paradigm.
And just another question:
Which restriction do you mean? Do you mean, the current restriction, that
there is only one quicktarter repo defined?
I like the idea of a CLI implementation, we should discuss this in the
open office hours.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opendevstack/ods-project-quickstarters/issues/254?email_source=notifications&email_token=AJV7CSGYWH3JOXLRIZTQYZ3P4ZQU7A5CNFSM4H34ABWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY26ZDI#issuecomment-506850445,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJV7CSGTS4SO6YAG7YBQIMLP4ZQU7ANCNFSM4H34ABWA
.

@michaelsauter happy you like the idea, too!
Here's a thought on how we could address those limitations: instead of having a fully local CLI, the CLI would be merely a client to a corresponding, RESTful web service that handles authentication and quickstarter-specific dependency management through Rundeck (or its successor). How do you manage authentication between the Provisioner App and BitBucket today? Depending on the authentication scenario, a single ods login might be achievable.
Thinking of impact vs. effort: it would already be super cool if the following snippet would simply create a repository in BitBucket based on the provided quickstarter type or URL. That means that the user would still have to clone the newly created repository into the workspace manually:
ods project $MY_PROJECT
ods quickstarter new <name> [--type|--url]

@tjaeschke with "arbitrary project structures" I am referring to giving freedom to developers when it comes to structuring an application across a single (mono-repo) versus multiple repositories. Currently, ODS mandates one repository for each component and hence does not support mono-repos. Here is why I think we need to reconsider.
When a git push for a change in a single component automatically leads to the execution of the component's Jenkins pipeline through the Webhook Proxy, then a change that spans more than one repository cannot be git pushed and released at once (atomically), and leads to intermittently failing components and experiences by design:

In a classical 3-tier architecture, a change in the backend is git pushed and released, and subsequently causes errors in the frontend until the frontend itself gets updated.

As a best practice, a change in one component should trigger integration tests for all components that depend on this component, and vice versa. However, a git push for a breaking change in the backend will cause tests for the frontend to fail, e.g., if the API contract between those two is violated. Generally speaking, as the number of services increase, the more efforts developers will have to put into releasing components in the right order (depending on the change). If the interdependence between some set of services shows a cyclic pattern, this problem is further aggravated.

Technically, some issues can be solved through the application of REST API versioning, circuit breakers, and other patterns of defensive programming, but these only deal with the symptoms. Actually, you don't want to depend on such practices, especially in the beginning, and instead rapidly prototype away to find customer value. Great tooling always supports a developer's way of working and avoids getting in the way. The introduction of unnecessary complexity causes frustration, which in turn is a primary cause for technical debt.
I understand that the current design is based on solid considerations. Besides the above reasoning, to me, forcing developers into managing the complexities of juggling multiple repositories from the beginning contradicts with the O in ODS. (This is also an open source project and we're not solely building it for us and experts only ;-)

@metmajer Yup something like this could work. I just wanted to outline some of the complexity involved, because when you first presented the idea I did not see that downside immediately. Maybe a service like the following would work:

Based on a URL/quickstarter type, create a repo in BitBucket with the webhook
Generate the files to be placed in that repo
If invoked from CLI, do NOT push the files to BitBucket but rather download the files to where the CLI was invoked from. If invoked from the prov-app, push the files to BitBucket.

Additionally, the CLI could have a flag to disable step 1, in order to place files in an already existing repo ...

@all, excellent ideas, all of them... however I think we need to discuss of roadmap 2.0 very carefully to create a solid ground for version 2.0... atm... I have the impression that big part of the effort goes into fixing things that we break when introducing new features... for that reason: CI/CD for ODS should be in imho first thing to put in place... secondly, we have a couple of security requirements that need to be addressed by end of 2019... having said that... @michaelsauter as answer for the scope question that you asked... I think any feature related to quickstarters that would simplify CI/CD and/or improve security are good candidates to be included in 2.0

@stitakis Did you read my list? Number 4 addresses this, I even added "Probably the most important requirement" :)

@michaelsauter of course I read it... good stuff! :)

@michaelsauter Love the suggestion, but I assume that support for arbitrary repository structures (not just their creation) will require some broader considerations to be made. I'd love to have a quick discussion with you to understand how far reaching a task this would be and how this fits into our upcoming and existing solutions. (Not meaning to exclude anyone here, but GitHub comments only take you so far.)
Here's to recap and slightly adapt your suggestion:

ods quickstarter new <name> ... calls the web service. The web service creates a BitBucket repo including all required files for the user to get started.
The CLI git clones the created repo into a subdirectory name underneath the current directory unless the user specifies a --directory option to override the default behavior. Once we know what it takes to support arbitrarily structured projects, we could introduce further (optional) options to control how to integrate the new component into the workspace next to git clone, such as Git Submodules to reference, develop, and deliver components from within a single repository.

I'd see the above solution as a lean approach, with the possibility to add more complexity on top as we have time and resources. Nevertheless, I can't image we'll continue to live on the 1 component = 1 repo for long because of the above-mentioned side effects. The farther we can get, the better, and I'd be happy to provide additional support.

@michaelsauter to the other discussion point on a "branching strategy" in quickstarters, I should have had a closer look before posting. Thanks for the pointer and being open for alternatives.
Right now, the branchToEnvironmentMapping is part of the pipeline implementation. Do we want to make this and other user-configurable aspects part of a central place, such as a /.pipeline-config.yml?
Aside from offering a central entry-point to adapting the behaviour of an application component, we already make use of the .pipeline-config.yml to communicate capabilities to an upcoming multi-repo orchestration pipeline that is currently being developed. Here are some examples:
Example: Repo Dependencies
Here, a repository exposes its dependencies on other repositories. This information will allow the orchestration pipeline to derive an execution plan from a dependency graph to build, deploy, test, and release an application's components into a live application in the correct order:
dependencies:
  - github.com/getcloudnative/B
  - github.com/opendevstack/C

Example: Pipeline Phases
Continuous Delivery pipelines can be reduced to a build, deploy, test and release process of phases. The following contract describes how these phases map to capabilities provided by the component. This will be a perfect fit to what's denoted under your point 7).
phases:
  build:
    tasks: [ build, unit-tests ]
    type: Makefile
  deploy:
    command: oc deploy --latest dc/A
    type: ShellScript
  ...

Example: Dependency Injection
The following example shows a contract that demands the pipeline to provide a set of environment variables. If those are unknown to the pipeline and can thus not be provided, the pipeline should fail.
environment:
  - AWS_ACCESS_KEY_ID
  - AWS_SECRET_ACCESS_KEY

Example: Branching Strategy
The last example describes which branches should be considered in some phases (ref. name) and which branches should be created in some other phases (ref. from and to).
phases:
  build:
    branches:
      - name: develop
        when: env == "Dev"
      - from: develop
        to: "release/v${VERSION}"
        when: env == "QA"

Thoughts?

@metmajer I am definitely open to move the branch-to-environment information elsewhere. The Jenkinsfile was just the most obvious place to put it at the time. A few things to think about in this context:

Should the branching model be a component concept, or a project concept? I feel that usually, teams would decide on a branching model across all components ... that said, the branching is "owned" by Git in the end, so somehow belongs to the component.
Reading a YAML file from Jenkins might be tricky. Right now the shared lib does not depend on approval of any methods, and it would be great to keep it that way. Do you know how easy/hard it is to read that YAML file?
I don't really get the "Branching Strategy" example. I assume dev is something known to the pipeline? But what does QA do when the release branch already exists? Just want to raise that I am not entirely sure what this does/means just by looking at it. The other examples make sense to me, definitely like the "Pipeline phases" suggestion.

Hmm. I am also not convinced yet. Currently it seems, that we rebuild something that is already part of a Jenkinsfile (stages, etc).
So lets start what where the Architectural Drivers of the initial solution and see, what other architectural drivers have come on the stage.
We started with the following drivers (not exhaustive)
Maintainability:

Use as much as possible from the standards as possible (OpenShift / Jenkins / ....)
Keep as integrated as possible
Keep effort to maintain base images as low as possible

Flexibility

Make it easy to adopt to any workflow that a team wants to choose
Understandability
Make sure, that it can be easily understood where changes have to be made
(Constraint): Focus on single component flow

Solution Strategy:

Use OpenShift Pipeline Build Strategy that employs Jenkins Pipelines
Jenkins Pipelines as a core concept that are easily understood by developers
Do not use any specific libraries / code that requires Jenkins script approval (and require changes of the slave base image)

Target audience:

Programmers (that should be comfortable with Jenkins Pipelines)

Trade-offs:

Configurations must be programmed in groovy instead of declared in a more declarative fashion
Limitiation in the available programming constructs / libraries

Probably you could add newly discovered architectural drivers behind your solution strategy.

The proposed changes in Michaels initial post contribute to the architectural drivers
Replacement of Rundeckt with Jenkins --> Maintainability (less different components, standards)
Multiple Quickstarter repos --> Flexibility
Proper Templating --> Maintainability
...
That' why I like the proposoals. Also the drive for more consistency (templates vs tailor files) that also helps understanbility.
We probably need to collect these architectural principals somewhere in the documentation

All, I am not proposing final solutions here. To me, the title of the story is an invitation to challenge the status quo. Don't think that I do not see the hard work everyone on this team has put into this project and, while I am hoping for many things to be changed, I will be happy to be part of this mission and contribute myself as needed.
My personal goal is to find ways to make ODS easier to onboard and use by people who are not engineering experts. I do fully support the design drivers! However, the biggest obstacle to a product's successful adoption in the enterprise has always been ease of use. The closest one that @rattermeyer describes is Flexibility, but that doesn't quite nail it for me. I'd like to see it less as "Make sure, that it can be easily understood where changes have to be made" and more as "Don't make me think".
@michaelsauter I feel it should be made configurable at the component level, too, but it could be defined and injected at the project level and passed on to the components through the orchestration pipeline as arguments.
For reading YAML files, I have been using the following library that can be loaded from within the Groovy sandboxed Jenkinsfiles even and doesn't cause any hick-ups:
@Grab('org.yaml:snakeyaml:1.24')
import org.yaml.snakeyaml.Yaml

I have also updated the branching strategy example which hopefully creates more clarity. Again, take my proposals as food for thought and hopefully lively discussions.

Thanks a lot for all the discussion! I'm closing this as a lot of what has been discussed in here will make it into release 2.
Everyone who still has concrete open topics after release 2 has been released, please open a new, focused issue.


Generic pass-through parser

Hey Chris, I merged this into develop earlier, so we don't need a pull request.


Naming RFC: drop Cells from gridPath, compact, uncompact

The name gridPathCells was originally intended to distinguish from future possible names like gridPathEdges or gridPathVertexes. However, gridPathCells is a bit of an awkward name, and we may never actually implement the edge and vertex versions.
Instead, we're proposing just gridPath.
This could extend to a general naming rule: When an H3 mode is not specified (cell, edge, vertex...), the user should assume the function pertains to Cells.

Coverage remained the same at 99.437% when pulling 4e5671fbd1470f41eef13708e7c1906e880f0bb8 on ajfriend:naming-rfc into 11fad0a3e46bf0b76de5d5eb35ba64dcaae1d55c on uber:master.

We might consider this new "cell is assumed if omitted" rule for a few other functions:

Current library name
Current RFC proposal

compact
compactCells

uncompact
uncompactCells

polyfill
polygonToCells

Of those, I think polygonToCells is an improvement, but the  compact/uncompact functions probably don't need the full specificity of "Cells", which can just be implicit. What would folks think about the following change to the RFC?

Current library name
New RFC proposal

compact
(unchanged)

uncompact
(unchanged)

polyfill
polygonToCells

Oh, you merged this before I could leave a comment. I don't really agree with this proposal. Or at least I don't agree with the partial application if we are going to make "Cells" a default choice. polyfill should be reverted back, as well, in my opinion.

By revert, do you mean the function could be called polyfill or it should be called polygonToCells?

By revert, do you mean the function could be called polyfill or polygonToCells?

In the context of this RFC, I'd put it back to polyfill. But if that isn't desired, I'd revert the RFC change itself and put Cells back on all of the functions? Being consistent one way or the other is what I mean.

I think the RFC as is is still fairly consistent, even with polygonToCells.

I think the RFC as is is still fairly consistent, even with polygonToCells.

I don't agree.

How I'm thinking about it (and why I don't think it causes any consistency issues) is that we have two types of function names here.

transformation names like <X>to<Y>
operation names like <Operation><H3_Mode>

Then polygonToCells has <X>to<Y> type.
Similarly, gridPath, compact, and uncompact are of <Operation><H3_Mode> type, but since

gridPathCells is a bit cumbersome to type (same with compactCells and uncompactCells),
Cells are the "default" mode that users will assume,
we may never actually implement these operations for other types, and
there's little chance of confusion,

we can drop the <H3_mode> and leave Cells as implicitly assumed.
That leaves us the option for things like gridPathDirectedEdge in the future, or even adding a gridPathCells alias.

For polyfill, I think a previous discussion (with @nrabinowitz?) came around to the idea that polygonToCells was a slightly more descriptive name.
I'm actually OK with either, but with a slight preference for polygonToCells.
And this is actually one of the operations that I think is most likely to have versions for different H3 Modes. Following the convention we have above, we would have the options:

polyfill
polygonTo<Y>

Cell
polyfill
polygonToCells

DirectedEdge
polyfillDirectedEdges
polygonToDirectedEdges

Vertex
polyfillVertexes
polygonToVertexes

With an optional alias or alternative name of polyfillCells.

Moving this conversation to https://github.com/uber/h3/issues/451


kompute : remove unused immintrin.h #include

With only this change, I am able to build the GPT4All backend with Vulkan support on Android, potentially leveraging the Qualcomm Adreno 660 GPU on my phone. I haven't tried to run it yet, but I think for now we can leave that to the users.

This fix has already been applied on master.


Migrate to AWS SDK2 for DynamoDB Provider

Feature Request - Support AWS SDK2 Client for DynamoDB
Many new projects prefer Amazon's Java SDK v2.  The current DynamoDB provider is backed by v1.
Proposed Solution
A clone of that DynamoDB module, naming to identify it as SDK v2 backed and refractoring against that SDK v2 would allow projects to avoid pulling SDK v1 into their dependencies.
Current Workaround
As a work around I implemented a LockProvider based on the v1 client but backed by the v2 client.

Thanks for reporting, I will take a look at it

Hi, could you please provide a pull request? I can't figure out how old API maps to the new one. The pull request does not have to be perfect, I just do not have the capacity to learn new API

Yes, I’ll submit a pull request in a couple days.


CLLocationManager prematurely responds with 'NotDetermined' as an auth status when asking for permission

I'm not sure why it thinks this is the right thing to do, but in some (but perhaps not all?) cases when asking CLLocationManager to authorize us for Location updates, it will immediately respond with 'NotDetermined' and then show the user the dialog asking for permission. After the dialog is dismissed, it proceeds to call us back with the proper status value.
Without this fix, adding a condition like this:
addCondition(AuthorizedFor(Capability.Location()))

will immediately fail our operation due to the premature callback.

Hi @J-Swift - thanks for this! I think this must be a regression either from the Swift 2.2 changes to capabilities or the conditions as operations stuff.
I can't get into it right now - but will do later this weekend!

Hmm, I think I must have found myself in between that big refactor for 'conditions as operations'. I was hotfixing my code locally with this based on a v2.10.0 release, then did a quick pull/update/push to get the PR submitted, not realizing that I wasn't operating on the latest version of the code.
So, this might/should be able to be put on hold until I verify that what I was seeing is still an issue or not with the refactorings you mention. Were you planning on cutting that release soon?

Not releasing v3 for a couple of weeks - but will fix this as v2.10.1 if needed, and then have the fix on development too.
Not had a chance to look into this - but will do tonight / a few hours.
Can you confirm if the issue exists on 2.10? 🤔😀

Switching back to v2.10.0 and testing on the sim I can't reproduce on a clean install, but can if I perform the following:

run on clean install
ask for permissions (this correctly does not trigger the callback early)
while the dialog is still on screen (i.e. without allowing/disallowing the permission), stop the sim
rerun the app
ask for permissions

This causes the premature failure I mentioned due to a .NotDetermined status. Perhaps the device is returning some sort of cached value that would have been created by that initial run-through?
I'll try and test on a device as well, but xcode is not allowing me to run on one at the moment so I can't test that unfortunately. I'll update here if I end up getting around said issue.

Okay, great. I'm back at my desk now, so looking into this now.
I think for this, I'm most interested in behaviour of while on device in an app. Previously, while it would essentially always query to see what the authorisation status was, the OS would only present the dialog if it were not determined. However, if the user had already responded to the challenge, then it would not re-present the dialog.
This is quite important, as the user could accept the authorisation request, and then later on, disable the permissions in their Settings.
So, I don't think you're change is an issue - but also, curious to see why it is happening - hoping it's just a result of the whole conditions as operations refactor.

So I still wasn't able to run through the xcode debugger, but building and installing as an adhoc, I was able to reproduce on the device in a similar fashion:

run on clean install
ask for permissions (this correctly does not trigger the callback early)
while the dialog is still on screen (i.e. without allowing/disallowing the permission), turn off the device
turn the device back on
rerun the app
ask for permissions

So, in a contrived but existing scenario, it is unfortunately still possible to be called back prematurely by the system.

Hi @J-Swift - can you share a bit of your code for how you're using the Location operations?
I've tried re-producing on a device this using my the Location example in my Permissions.app - but behaves pretty much as expected. This is using v2.10.

Looking at development now.

So, yes - definitely an issue with development as it runs the dependency immediately.

To be clear, this is regarding the LocationCondition, not LocationOperations. Here is a pared down example of my class (please disregard poor swift abilities, I have very limited experience with it). It is triggered when a user enables location tracking within a settings page:
public class RequestUserLocationTrackingOperation : Operation {
  private let _onComplete: (Bool -> Void)?

  public init(onComplete: (Bool -> Void)? = nil ) {
    _onComplete = onComplete
    super.init()

    addCondition(AuthorizedFor(Capability.Location(.WhenInUse)))
    addCondition(MutuallyExclusive<RequestUserLocationTrackingOperation>())
  }

  override convenience init() {
    self.init(onComplete: nil)
  }

  // MARK: Operation

  public override func execute() {
    Capability.Location().authorizationStatus { (status) in
      switch (status) {
      case .AuthorizedWhenInUse, .AuthorizedAlways:
        self.finish()
      case .Restricted, .Denied:
        self.finish(OperationError.ConditionFailed)
      default:
        // no-op
        print("DEFAULT")
      }
    }
  }

  public override func finished(errors: [ErrorType]) {
    super.finished(errors)
    dispatch_async(dispatch_get_main_queue()) {
      self._onComplete?(errors.count == 0);
    }
  }
}

Here is a run with logging for the buggy case:
Unnamed Operation:  >>> MutuallyExclusive<RequestUserLocationTrackingOperation>
Authorize Location.WhenInUse:  >>> MutuallyExclusive<LocationCapability>
Authorize Location.WhenInUse: Initialized -> Pending
Authorize Location.WhenInUse: Pending -> EvaluatingConditions
Unnamed Operation: Initialized -> Pending
Authorize Location.WhenInUse: EvaluatingConditions -> Ready
Authorize Location.WhenInUse: Ready -> Executing
Authorize Location.WhenInUse: Will Execute
Authorize Location.WhenInUse: Executing -> Finishing
Authorize Location.WhenInUse: Finishing with no errors.
Authorize Location.WhenInUse: Finishing -> Finished
Unnamed Operation: Pending -> EvaluatingConditions
Authorize Location.WhenInUse:  <<< MutuallyExclusive<LocationCapability>
Unnamed Operation: EvaluatingConditions -> Ready
Unnamed Operation: Ready -> Finishing
Unnamed Operation: Finishing with errors: [Operations.CapabilityError<Operations.LocationCapability>.AuthorizationNotGranted(__C.CLAuthorizationStatus, Optional(Operations.LocationUsage.WhenInUse))].
Unnamed Operation: Finishing -> Finished
Unnamed Operation:  <<< MutuallyExclusive<RequestUserLocationTrackingOperation>

And one with the fix:
Unnamed Operation:  >>> MutuallyExclusive<RequestUserLocationTrackingOperation>
Authorize Location.WhenInUse:  >>> MutuallyExclusive<LocationCapability>
Authorize Location.WhenInUse: Initialized -> Pending
Authorize Location.WhenInUse: Pending -> EvaluatingConditions
Unnamed Operation: Initialized -> Pending
Authorize Location.WhenInUse: EvaluatingConditions -> Ready
Authorize Location.WhenInUse: Ready -> Executing
Authorize Location.WhenInUse: Will Execute
Authorize Location.WhenInUse: Executing -> Finishing
Authorize Location.WhenInUse: Finishing with no errors.
Authorize Location.WhenInUse: Finishing -> Finished
Unnamed Operation: Pending -> EvaluatingConditions
Authorize Location.WhenInUse:  <<< MutuallyExclusive<LocationCapability>
Unnamed Operation: EvaluatingConditions -> Ready
Unnamed Operation: Ready -> Executing
Unnamed Operation: Will Execute
Unnamed Operation: Executing -> Finishing
Unnamed Operation: Finishing with no errors.
Unnamed Operation: Finishing -> Finished
Unnamed Operation:  <<< MutuallyExclusive<RequestUserLocationTrackingOperation>

And this is using v2.10?

This is based on me cherry-picking my PR onto master at the moment, then commenting/uncommenting the tweak:
https://github.com/J-Swift/Operations/tree/master

And, can you clarify - how are you responding to the dialog? It looks like you're denying permission?

In the 'fixed' log I'm allowing permission.
In the 'buggy' log I'm not responding, that is the condition failing prematurely which causes the operation to finish without executing. The dialog is still on screen at this point. If I then allow/deny nothing else gets logged regardless of my choice (but the system does correctly store that choice as evidenced by future retrieval of the permission).

Okay, so sorry about this - but I don't quite follow what the issue is - how is it not working?
If you turn off the device or quite the app before responding, is it not unreasonable that the operation finishes - more than likely because the NSOperationQueue is deallocated when the app is quit - and it'll cancel all the operations.
The dialog is out of process - if you quit the app while the dialog is open, and then respond, the OS remembers the authorisation permission - and it gets retrieved correctly. Which seems reasonable...
What am I missing?

Perhaps you can explain what you're trying to do too? I think maybe there is some mis-understanding about what AuthorizedFor does/is for. Given the execute method of your operation - are you just trying to check the CLLocationAuthorizationStatus? Or do you want to execute an Operation only if authorised?

The usecase is that I want to allow enabling location tracking as a setting in a settings page.
So, to do that I wrap the AuthorizedFor capability as a condition of an operation. The intended flow is then, run the condition and check in our own execute block what the result was so that we can callback to our settings UI to let them know the result.
The issue arises due to a situation where the condition will prematurely fail due to the system calling it back with .NotDetermined immediately upon being asked to requestAuthorization. We correctly handle the 'happy' path of this being returned as the current system status but the issue is that this is then also returned immediately upon calling requestAuthorization. This is due to the delegate method not being prepared for .NotDetermined as a possible status code when being called.
So, while we expect the following to happen:

Check status
See that we are .NotDetermined
Request authorization
(system presents auth dialog)
(user answers dialog)
Get called back with either .Denied or .Authorized
Check if the callback status means we were granted permission. If .Denied then we were denied and if .Authorized then we were granted

We are actually having this happen:

Check status
See that we are .NotDetermined
Request authorization
Get called back immediately with .NotDetermined
Interpret .NotDetermined as being denied permission

Meanwhile during the last two steps, the following is also occurring after we have completed our AuthorizedFor capability check:

(system presents auth dialog)
(user answers dialog)

Does this make sense? To be clear, I think this is a bug with CLLocationManager, but it is something that I'm trying to work around by being prepared for it.

Okay - I think I can see what is going on. When a condition is attached to an operation, it is either satisfied, or it fails with an error. An operation can have multiple conditions. If any fail, the operation does not execute - it finishes immediately with an error.
In other words, the operation will only run if all its conditions are satisfied.
If you want to run an operation, and respond to the CLLocationAuthorizationStatus attaching a Capability.Location is not the way to do it - as you'll never know if the user denied access. The condition will fail if authorisation is denied.
Instead, use GetAuthorizationStatus and Authorize which are two Operation subclasses which can be used to query for the authorization status, and explicitly request authorization of any capability.
So, you can use them like this:
let getStatus = GetAuthorizationStatus(Capability.Location()) { enabled, status in
    // setup UI to reflect the status - consider writing this as a function.
}
queue.addOperation(getStatus)

To explicitly request authorization:
let authorise = Authorise(Capability.Location()) { enabled, status in
    // setup UI to reflect the status - consider writing this as a function.
    // Notice that the closure signature is the same as GetAuthorizationStatus
    // This is so that the same function can be used.
}
queue.addOperation(authorize)

You can use combinations of SilentCondition and NegatedCondition in order to show or hide different UI elements depending on the authorisation status.
I strong recommend you look at the Permissions.app sample code to see how this is done.
Perhaps also read the programming guide on Capabilities if you haven't had a chance yet.

Dan, I really appreciate you taking the time on this. I don't think you quite understand my point I'm trying to illustrate however. My use case, while maybe being a slightly wonky use of the available tools you provide, is tangential to the buggy CLLocationManager behavior.
I've gone ahead and recreated the issue on the Permissions.app to hopefully give a bit more clarity:
https://www.dropbox.com/s/xzdxzrtuiu5uhwr/cllocation_issues.mov?dl=0
Note a few things in this. First, the initial run shows that the operation is waiting for our input while the alert is on screen. Second, the next run immediately finishes the operation without waiting for our input. Third, no further operation actions are logged after allowing the permission because the operation has already completed at this point.
Now, in this specific setup that you have with the Permissions.app it turns out that the premature failure doesn't actually have any side-effects that might affect the experience. However, you might imagine a situation where mutual exclusivity guarantees are violated by the operation finishing but still being 'in flight', or in my case the UI callback is structured in a way that interprets the callback as being 'denied' permission even though no permission has actually been given at the point of callback.

Hi @J-Swift - I guess I just don't really see what the issue is. I watched the video - don't see what the issue is. You're gonna have to explain it better. Sorry! 🤔

Watch the logging while the app is being used.
In the first run through, notice how when the alert is on screen the logging indicates that we are in the 'executing' phase and remains that way.
In the second run through, notice how when the alert is on screen the logging indicates that we immediately go from 'executing' to 'finishing'. The alert is still on screen. We haven't made a choice yet. The operation has already completed and the alert is still on screen.

Hi @J-Swift - sorry for the delay, bit crazy at work.
But yep - been able to reproduce this - got there in the end 😁. Seems like a bit of a undefined behaviour about how CLLocationManager reports the status changes to its delegate.
Will merge this PR, but I will look at cherry picking the change into a point release for v2.10.1. I also want to go through all the other capabilities which wrap system permissions to check them too.

Thanks Dan, and thanks for the library. I tried PSOperations for a brief bit but converted to your version after seeing how much time you've put into your documentation and examples. That has made a big difference in getting things going, so thanks for putting all your time into it.


unknown vehicle getting automatically spawned in the world

Hi,

This is what I first did to remove all actors from the world :
Python 3.5.6 |Anaconda, Inc.| (default, Aug 26 2018, 21:41:56)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import carla
carla_client = carla.Client('<IP_ADDRESS>', 2006)
carla_world= carla_client.get_world()
actor_list = carla_world.get_actors().filter('vehicle.*')
print(actor_list)
[]

Through a script I spawned a vehicle in the world :
Selected Actor :  vehicle.audi.a2
number_of_wheels : ActorAttribute(id=number_of_wheels,type=int,value=4(const))
object_type : ActorAttribute(id=object_type,type=str,value=(const))
color : ActorAttribute(id=color,type=Color,value=Color(224,0,0,255))
role_name : ActorAttribute(id=role_name,type=str,value=hero)
Selected Location :
Location(x=237.7, y=129.75, z=39.4306)
Actor List =
[Actor(id=86, type=vehicle.gazelle.omafiets), Actor(id=87, type=vehicle.audi.a2)]

This happened many times, I am not getting from where the second vehicle (Actor(id=86, type=vehicle.gazelle.omafiets)) is coming into the world.

Could you provide your code?


Reformat based on official Airflow Best Practices

fix issue with ReplaceVariableGetByJinja
add new rule ReplaceTopLevelImportByFunctionLevelImport

Codecov Report

Merging #8 (6dd8339) into main (8787be4) will decrease coverage by 2.51%.
The diff coverage is 93.22%.

@@            Coverage Diff             @@
##             main       #8      +/-   ##
==========================================
- Coverage   91.66%   89.15%   -2.52%
==========================================
  Files           8        6       -2
  Lines         156       83      -73
==========================================
- Hits          143       74      -69
+ Misses         13        9       -4

Impacted Files
Coverage Δ

airflint/__main__.py
0.00% <0.00%> (ø)

airflint/rules/use_jinja_variable_get.py
88.88% <75.00%> (ø)

airflint/actions/move_statements.py
100.00% <100.00%> (ø)

airflint/representatives/import_finder.py
100.00% <100.00%> (ø)

airflint/rules/use_function_level_imports.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Diff never resolves

Notice the error in the dev tools.
Monaco editor playground repro

Thanks for finding this! One of the very few bugs in the diff algorithm.


Flow does not catch assignment to imported const

a.js
// @flow
export const C = 7;
//C = 8; // this will trigger "const cannot be reassigned" error

b.js
// @flow
import {C} from "./a"
C = 8; // this will not

What is interesting, is that babel catch this with "C" is read-only, even in form if (false) C = 8;

Thanks for the report!
It's true that an imported const is an error just as assigning to any const would be.
Additionally: While it's true that assignments to imported lets and vars are not an error in pure JS, they are a silent no-op -- so it makes sense that we should just always give an error for them as well.


Improvements to the release process

Today we have a release process that is relatively simple: push a tag, a team member needs to approve, the pipeline runs, and there is a draft release ready for someone to manually publish. In about 20 minutes you could go from "need to release" to "release is published" state. That being said, there are still some frictions here, I'll highlight a few that come to mind for me:

Since we need to run on a mac for the signing step and we need docker for other steps in the the build process, we end up needing to install docker on a mac. This is about 10 - 13 minutes --half of the release process.  Tracked in https://github.com/anchore/syft/issues/577
~The current changelog generator takes a few minutes to run, where the set of API calls to GitHub seems to be the limiting factor here. We have a relatively small repo and am a little surprised at the running time.~  Chronicle has been integrated to alleviate this problem
We have a GPG signing step which we never finished (never published the public key), though the potential value for finishing this is high from a security perspective, key management and long term support doesn't seem appealing. There are probably better ways to do this today.

Some of these frictions hint at changes we can make, but this also good time to look for opportunities to improve the release process as a whole.
Feel free to add on frictions you've noticed or opportunities we should consider.

It also looks like we can update how we're using the seucrity scan action:
--
1 issue was detected with this workflow: git checkout HEAD^2 is no longer necessary.
Please remove this step as Code Scanning recommends analyzing the merge commit for best results.

This is a great issue. Adding a few frictions I've seen:

Tagging a commit before we're certain that we're releasing from that commit can cause issues for consumers of our code. Anecdotally, several folks seem to trust that a release tag won't change, once applied. This expectation is intensified in the Go world, because the first time anyone consumes our Go module at the tag, that tag is bound to a digest of our module in the public Go proxy, such that if we re-tag later, users trying to consume the updated tag will see errors from the Go toolchain. Since there exists a perceived "finality" to release tags, it'd be great to find a way not to tag until the release is final.
We publish updated Docker images and homebrew formulae for releases before the releases are confirmed. If we look at a release draft and decide to substantially change or cancel the release, a burden is placed on the release operators to remember to unpublish the Docker images and homebrew formulae.

concept branch for half of possible solution 2: https://github.com/anchore/syft/compare/refactor-release (note, this branches from the install.sh work done previously, so needs to be rebased/cleaned-up when the install.sh PR lands)
This splits up the signing and notarization, and enables a local signing workflow that is always done with snapshot builds.

Great issue. Adding an item to the list:

Document the manual publishing step.


Discoverability of data on RootAuthorities, Policies, Auditors, Installers etc

Problem description
As a Guardian user I would like to be able to navigate easily across and see all interrelated items of all types (RootAuthority and other users/roles, VCs, tokens, schemas, policies, etc) as well as to be able to extract the data in an appropriate format for import into or use by other programs (for further analysis).
Requirements

Introduce a dashboard view of a single entitie's immediate relationship with other types of entities. The dashboard contains multiple tables - one for each type (e.g. Auditors) - each showing the list of entities of this type that the current entity is somehow related to. Content changes when the user clicks on the entity (navigating from the RootAuthority to an Auditor for example) in such a way that now the clicked entity becomes the focus of view and thus new tables appear showing direct relationships with the 'current' entity. There is a back and forward buttons to navigate the relationships.
Introduce a dynamic graphical view of the interrelationships between Guardian entities presented in a form of Force-Directed-Graph or a similar display. Consider the possibility of using D3 or Highcharts libraries for this.
Introduce ability to export this analytics data in the JSON format for import/transformation by other analytics programs (see neo4j for inspiration)

DOD

Ability to view, navigate and understand through the UI the relationships between all entities under a single RootAuthority
A useable API interface for others (possibly used by the export functionality above) to retrieve the data
Acceptance criteria fulfilled

Acceptance criteria

Via using The UI and APIs described above users are able to answer the following types of queries:

what roles and actors have been given credentials by this RootAuthority, what permissions they have
which policies (single or multiple) those actors work on
how many credentials have they given to a specific device or project
show quantitative output of those roles and actors in project token
how many actors are tied into what projects
what type of transactions on what project
show aggregates of the 'ecosystem' such as X Amount of Project Initiators, X Amount of Tokens, X Amount of Subcategory, X Amount of classifications, Metric Tonnage in Emission or Offsets
how many tokens created by a policy,  how many tokens created by the policy over a period of time
what are the quantitative amounts in units of account (could be a metric ton of carbon) represented by the created tokens
where tokens encumbered
where were the tokens sent
what is the price of the token

See TRM Labs or Chainanalysis for inspiration.

Next step is for Andrey to Review.

@envisionblockchainpm while I understand the general direction here, I don't understand specifically for the scope of this ticket:

does the analytics cover single (this, current) Guardian instance or should it show information that may have been created through a different Guardian instance
how do those notes above relate to the 'single policy' - reading them they seem to be very broad and talking about single 'RootAuthority' not a single policy

Brainstorming with Wes and Max - changed the title ('single policy analytics') as it was misleading. The analytics that is required is to show everything related to everything, rooted in the 'RootAuthority' entity down the tree all the way to the tokens. To give user the ability to see related entities of all types in the system, and the navigate the focus layer by layer, e.g. for a Policy to see who issued the policy, who uses the policy, which tokens been created under this policy etc.

Next step: to find a suitable UI concept visually depicting interrelationships between entities and the corresponding statistics.

Having thought more about this, I believe we aim to use both grid (with filtering) to navigate the data and chart - specifically 'force directed graph' to display the relationship visually. I previously had good experience with Highcharts library.
Next steps:

@Pyatakov is it technically feasible to use Highcharts in the OS Guardian?
@sergmetelin and @danielnorkin is Highcharts license model (free for non-profits) compatible with the context of OS Guardian?
@envisionblockchainpm need to ask @mendelenvisionblockchain to design UX for this

Hi Team, please see attached an outline of some metrics and information that would be useful to be able to discover/capture. Please let me know if you have any qu
Issue 309_Data Discoverability-Analytics Priority Metrics 2-8-22.docx
estions or comments. @anvabr


Carry 21716: When container had no layer data, cleanupContainer crashed

Carry of #21716
Closes #21716

This is only a rebase, and was already reviewed, so moving to "merge"

Flaky test on WindowsTP5 ? https://jenkins.dockerproject.org/job/Docker-PRs-WoW-TP5/111/console
17:02:57 ----------------------------------------------------------------------
17:02:57 FAIL: docker_cli_ps_test.go:303: DockerSuite.TestPsListContainersFilterID
17:02:57
17:02:57 docker_cli_ps_test.go:309:
17:02:57     // start another container
17:02:57     runSleepingContainer(c)
17:02:57 C:/gopath/src/github.com/docker/docker/pkg/integration/dockerCmd_utils.go:42:
17:02:57     c.Assert(err, check.IsNil, check.Commentf(quote+"%v"+quote+" failed with errors: %s, %v", strings.Join(args, " "), out, err))
17:02:57 ... value *exec.ExitError = &exec.ExitError{ProcessState:(*os.ProcessState)(0xc08252c020)} ("exit status 127")
17:02:57 ... "run -d busybox sleep 240" failed with errors: 0cfcaef96d9f60450ba1bc264fac37094e858898907c381f6a6c05fe2866ab68
17:02:57 D:\CI\CI-0bfc9c8\binary\docker.exe: Error response from daemon: Container command 'C:/busybox/busybox.exe' not found or does not exist.
17:02:57 , exit status 127
17:02:57

Known TP5 bug. Not a flaky test. We're investigating the cause of those class of errors.

@jhowardmsft alright, let's ignore that one for now then


exploitdb: 2021-11-23 -> 2021-11-24

Motivation for this change
update to 2021-11-24
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 147273 run on x86_64-linux 1

1 package built:

exploitdb


Error:'Where is not recogized". while creating flutter app in android studio

I got the this error: "where is not recognized as internal and external command,operable program or batch file" while creating Flutter testing app on android studio.
I did run "Flutter doctor" in cmd, I got no error here. And also I have installed flutter through plugins in android studio. Added the path for sdk tools properly.
But still I'm getting the above error.
Please help me!

Hi @salmanahamedg
given this message could you please make sure
that your set-up fulfils the system requirements;
after that please run from your terminal and with a device (physical or virtual) attached
flutter upgrade -f
flutter doctor -v
flutter create test
cd test
flutter run -v

let me know if the issue persist
Thank you

When I typed the 3rd command , I got an error:
"Invalid project name: 'test' - this will conflict with Flutter package dependencies."
Thanks for help @iapicca
My issue is still there. Please help me

Hi @salmanahamedg
my bad, I've updated the command,
please try again
Thank you

This error also occurs if the path to the system32 folder is not present in the system environment variable.
you can directly add it by copy-pasting the path to system env. ('C:\Windows\System32' for my case this is the path and in most cases the path is same)
alternatively, you can check the presence of system32 path by running
where flutter
in the command line which will provide the path to you flutter installation directory
gen syntax for using where is
where
(general syntax: where  // By default, the search is done along the current directory and
in the paths specified by the PATH environment variable.)
Hope this solves the issue.
Thank you

Hi @salmanahamedg
my bad, I've updated the command,
please try again
Thank you

Hi @iapicca
It worked till the last line. After that I got this error:
"'where' is not recognized as an internal or external command,
operable program or batch file.
Error: Unable to find git in your PATH."

@SANSKARJAIN2
Still I'm getting error
Help appreciated.
Thank you

Could everyone who still has this problem please file a new issue with the exact description of what happens, logs and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.

Thank you so much @SANSKARJAIN2
I didn't add C:\Windows\System32 path to env
It worked out


Remove double-spacing typo in JS/Basic Javascript/Concatenating-Strings-With-Plus-Operator

Checklist:

[X] I have read freeCodeCamp's contribution guidelines.
[X] My pull request has a descriptive title (not a vague title like Update index.md)
[X] My pull request targets the master branch of freeCodeCamp.
[X] All the files I changed are in the same world language, for example: only English changes, or only Chinese changes, etc.

Closes #39007

This is my first PR so I am hoping I did this correctly. This corrects the typo pointed out in the linked issue.

LGTM!

@nhcarrigan Congrats on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝


Dashboard Server remote mode

Affected ROS2 Driver version(s)
humble
Used ROS distribution.
Humble
Which combination of platform is the ROS driver running on.
Ubuntu Linux with standard kernel
How is the UR ROS2 Driver installed.
Build both the ROS driver and UR Client Library from source
Which robot platform is the driver connected to.
Real robot
Robot SW / URSim version(s)
latest
How is the ROS driver used.
Through the robot teach pendant using External Control URCap
Issue details
Summary
Short introduction to the issue and how it impact you and why
Is there a way to query if the dashboard server is in Remote mode?
Issue details
Detailed description help us understand the problem. Code are welcome!
Steps to Reproduce
Make simple example to reproduce the issue. Try to remove dependencies to other hardware and software components, if it is possible.
Expected Behavior
What did you expect and why?
Actual Behavior
What did you observe? If possible please attach relevant information.
Workaround Suggestion
If a workaround has been found, you are welcome to share it.
Relevant log output
No response
Accept Public visibility

[X] I agree to make this context public

We currently don't have a direct service call to support this, but the dashboard server itself supports querying for remote control mode. For a full dashboard server documentation, please see https://www.universal-robots.com/articles/ur/dashboard-server-e-series-port-29999/
In short, you can make any dashboard call using the raw_request service:
$ ros2 service call /dashboard_client/raw_request ur_dashboard_msgs/srv/RawRequest "query: 'is in remote control'"               [ur_rolling]
waiting for service to become available...
requester: making request: ur_dashboard_msgs.srv.RawRequest_Request(query='is in remote control')

response:
ur_dashboard_msgs.srv.RawRequest_Response(answer='true')

Thank you @urfeex This is truly very helpful.

Glad I could help


Compilation errors regarding Analytics

After updating Analytics to version 4.1.2 and Segment-Singular to version 1.2.0, I'm getting errors on a couple #import statements such as SEGIntegrationFactory.h

I created a new empty project using Xcode 12.2 and put 2 pods into the podfile:
 pod 'Analytics'   pod 'Segment-Singular'
After doing a pod install and opening the resulting .xcworkplace, I am unable to compile because of the pods not working together.


Feature/5293: Configure maximum number of attempts when trying to lock SH and SP for connection creation.

Codecov Report

Merging #4 into master will decrease coverage by 0.23%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##           master       #4      +/-   ##
==========================================
- Coverage   67.92%   67.69%   -0.24%
==========================================
  Files          12       12
  Lines         873      879       +6
==========================================
+ Hits          593      595       +2
- Misses        280      284       +4

Impacted Files
Coverage Δ

networking_oneview/conf/oneview.py
100% <ø> (ø)
:arrow_up:

networking_oneview/ml2/drivers/oneview/common.py
73.46% <71.42%> (-1.01%)
:arrow_down:

Continue to review full report at Codecov.

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


Fix pages build

Fix for #523
Couldn't resist also fixing the fuzziness of the logo

Codecov Report

Merging #526 (f47b9e7) into main (57c43c4) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #526   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          275       275
  Lines        15812     15812
=========================================
  Hits         15812     15812

Continue to review full report at Codecov.

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


fix(semantic): transformer checker compare binding symbol IDs

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#5057  👈
#5056
#5055
#5054
#5053
#5052
#5051
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @overlookmotel and the rest of your teammates on  Graphite


Audio delay introduced after running the patcher

So I only just noticed this very recently, and at first, I thought it was Bluetooth being Bluetooth and suffering from some delay since that's what I had been using for a while. But then when I went and watched some youtube with my wired headphones, that's when I knew something was up. I verified it, and its definitely not the browser, or anything else, but after I run the patcher, it causes a delay. it fixes V4W, but this new problem is a rather big one for me.

Ok so I reinstalled it again, after removing my audio driver, (high def audio driver, not realtek or anything) and this time, the issue would go away when v4w was turned off, but in previous instances, it did not go away when it was turned off, just FYI.

@alecfs24  Although You know it's getting hard if the original developer of ViPER4Windows not continue developing their software ... so I'm going to work as far I can in some days..update this patcher.. get subscribed..


Added Referral and Redeem Code Section.

Issue Number
fixes #279

Describe the changes you've made

Describe if there is any unusual behavior (Any Warning) of your code(Write NA if there isn't)

Added Referral and Redeem Code  Section.
Additional context (OPTIONAL)

Test plan (OPTIONAL)
A good test plan should give instructions that someone else can easily follow.

Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] The title of my pull request is a short description of the requested changes.

https://user-images.githubusercontent.com/47661086/115951747-1b356800-a500-11eb-8bc3-15b92390cd23.mp4
Provide a Deployed link of route/page that needs to review
Preview: Deployed preview link
<!-- Please add deployed link to here text >

@Abhishek-kumar09 @vasudev19126  ping!

Hey, @Abhishek-kumar09  @vasudev19126   the changes required some functionality like

Sharing a referral on a different chat platform  available in the user's device,
Adding the functionality of copy redeem code,
And adding functionality  to  *T&C  apply
As the UI changes get Approve I would love to work on this after if you agree with the thought 😊.


[cluster-test] Emit transactions when running network delay simulations

Summary
This PR updates the multi_region_network_simulation experiment such that transactions are generated in the background. Without that, we would be simply processing empty blocks in the experiment.
Test Plan
Ran against my cluster.

@bors-libra r+

:pushpin: Commit 3cc4d34 has been approved by andll

:hourglass: Testing commit 3cc4d34b7c456b7324b8ff46faf8ccbab8a81408 with merge 05fac4310365015d900551cd90c76209d8556ef2...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: andll
Pushing 05fac4310365015d900551cd90c76209d8556ef2 to master...


Live Demo link Is Not Available

@ashishsiot, I just noticed you posted this issue last month. What is the issue you are seeing? https://player-html-remix.glitch.me/src/player.html works for me, and there is a link to it from the README.md.

Thank You For Providing Link


VIM-2113 Increase tag range only in visual mode

Hi! Thank you for your contribution and sorry for the delay in reviewing 🎉


Unable to login in https://container-registry.oracle.com/

Hi,
I'm trying to login to https://container-registry.oracle.com/ to install the weblogic docker image on my windows 10 PC, but when I execute the docker login command and after providing the correct username and password I'm prompted with the error:
Error response from daemon: Get https://container-registry-phx.oracle.com/v2/: unauthorized: authentication required
I've verified my user is in the local windows docker-users group.
I've then verified that I can login via browser on the webpage https://container-registry.oracle.com/  and that I accepted the Oracle Standard Terms and Restrictions on the weblogic related web page so there should be no issue there.
I've also tried to login from a different PC, a linux machine with OMV5, but after providing the right username and password I'm prompted with a different error:
Error reponse from daemon: Get https://container-registry-phx.oracle.com/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Do you have any advice?
Thank you

Remove the -phx from the URL.

Hi Djelibeybi , thank you, but the docker login command I run is without the -phx:
docker login container-registry.oracle.com
I think I'm redirected to it, but don't know why.
Thank you.

I can't reproduce this locally unfortunately. It's logging me just fine. Strictly speaking we don't really support the Oracle Container Registry here on GitHub, but if you have an Oracle Linux support subscription, you can open an SR with Oracle Support.
However, you could just build your own WebLogic image using the files provided on this very repo. :)

Thank you, will do!

Hi ,
I'm sorry but also to build my weblogic image with the code in this repo requires the docker login in order to download the JRE... I will try to modify it and see if I can provide my own JRE to build it.
Any hints on where to look for it?
Thank you.

Hi Djelibeybi,
I've tried to build my own using the code on this repo, but it still requires the docker login to work in order to download the oracle server/serverjre:8 image:
pull access denied for oracle/serverjre, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
And I don't think I can get around that... or can I? Can you think about a workaround?
Thank you again for your help.

You can build the JRE as well using Dockerfiles in this repo too. :) The only thing you need to be able to pull is the official Oracle Linux image from Docker Hub (which doesn't require a login).

If you go to https://github.com/oracle/docker-images/tree/master/OracleJava/java-8 you can build a serverjre:8 image yourself.  There is also a

Thank you very much guys, I've tried to build the serverjre image from the link provided by mriccell, but it seems that when it tries to install tar and gzip it can't get to the yum oracle repository:
https://yum.oracle.com/repo/OracleLinux/OL7/UEKR5/x86_64/repodata/repomd.xml: [Errno 14] curl#6 - "Could not resolve host: yum.oracle.com; Name or service not known"
I can access though yum.oracle.com and the link specified with no problem with my browser, and I've checked that docker has the correct proxy configured, I can pull images from the docker offical repo.
Do you have any other suggestions?
Thank you again for your help.

You're having networking issues with Docker that are unrelated to this repo. I suggest trying to get help from a Docker specific repo or forum and once you get that working, try these builds again.

Thank you, will do, thanks again for the help


Fix wrong redirect behavior (MC-256419)

Overview
Brigadier set the variable foundCommand to true HERE even if no Command<S> was executed, and this cause a serious problem.
An example to this is in minecraft: if you execute the command /xp query Steve, you will not receive an error message from the server. This is because that xp is redirected from experience, and when brigadier found this command is redirected, it set foundCommand to true--even if nothing is actually executed.
Ways to fix
I think the best way is to remove this wrong assignment. I tried in fabric to modify this code like below, and it works.
package com.github.zly2006.testmod.mixin;

import com.mojang.brigadier.CommandDispatcher;
import com.mojang.brigadier.ParseResults;
import com.mojang.brigadier.context.CommandContext;
import org.spongepowered.asm.mixin.Mixin;
import org.spongepowered.asm.mixin.injection.At;
import org.spongepowered.asm.mixin.injection.Inject;
import org.spongepowered.asm.mixin.injection.ModifyVariable;
import org.spongepowered.asm.mixin.injection.callback.CallbackInfoReturnable;
import org.spongepowered.asm.mixin.injection.callback.LocalCapture;

import java.util.ArrayList;
import java.util.List;

@Mixin(value = CommandDispatcher.class, remap = false)
public class MixinCommandDispatcher {
    boolean modify = false;
    boolean valueBefore = false;
    @ModifyVariable(method = "execute(Lcom/mojang/brigadier/ParseResults;)I", at = @At(value = "STORE"), ordinal = 1)
    private boolean modify(boolean v) {
        if (modify) {
            modify = false;
            return valueBefore;
        }
        return v;
    }

    @Inject(method = "execute(Lcom/mojang/brigadier/ParseResults;)I", at = @At(value = "INVOKE", target = "Lcom/mojang/brigadier/context/CommandContext;hasNodes()Z"), locals = LocalCapture.CAPTURE_FAILSOFT)
    private void checkFix(ParseResults<?> parse, CallbackInfoReturnable<Integer> cir, int result, int successfulForks, boolean forked, boolean foundCommand, String command, CommandContext<?> original, List<?> contexts, ArrayList<?> next, int size, int i, CommandContext<?> context, CommandContext<?> child) {
        if (child.hasNodes()) {
            modify = true;
            valueBefore = foundCommand;
        }
        else {
            modify = false;
        }
    }
}

The result after my modification was tested in Minecraft 1.19. With this modification, /xp query Steve will throw a CommandSyntaxException as expected and an error message from the server was received.

This bug is also reported at JIRA.

Seems that https://bugs.mojang.com/browse/MC-256419 and https://bugs.mojang.com/browse/MC-165773 can be closed as fixed. @slicedlime @Gegy

Not quite - they will be closed when a Minecraft version is released using the updated library.


During page reload, css styles seems to be loaded last in Nuxt Bridge but working correctly in Nuxt 3

Environment
Node Version: v16.16.4
Nuxt Version: Nuxt-Edge Latest
Nuxt Bridge: 3.0.0-27657000
Package Manager: npm
Bundler: Webpack
Reproduction

Created a nuxt 2 app and upgraded it to Nuxt bridge.
Installed Tailwind as described in the docs.
CSS Styles are not loading for a second after refresh.

Describe the bug
When page reload, css styles are not loading for a second in Nuxt Bridge but I have tried it out using Nuxt3 and it's working correctly.
Additional context
No response
Logs
No response

@azelalynetan provide a reproduction at https://stackblitz.com/
@danielroe looks like a duplicate of https://github.com/windicss/nuxt-windicss/issues/159


Adding QuadrigaCX support

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

feature

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Adds support for the QuadrigaCX exchange.

Other information:

I've been able to test most functionality but live trading, I've taken this nearly as a direct port from an implementation that was checked live in another bot, so it should be fairly reliable.

:+1: yet another great PR. Will merge to develop and test it soon :)


NAP policy manifests

[x] create NAP policy for bots and threat campaigns with all signatures turned off
[x] create NAP policy for DoS

nap policy in 5f564b9 and dos policy in 74b83ec


Add adapter ecoflow to latest

RE-CHECK!

RE-CHECK!

RE-CHECK!

RE-CHECK!

Automated adapter checker
ioBroker.ecoflow

:thumbsup: No errors found

[ ] :eyes: [W400] Cannot find "ecoflow" in latest repository

Add comment "RE-CHECK!" to start check anew