Decide on naming of modules

With abstract-level, there is no "down" or "up" anymore. For example, memdown does not have to be wrapped with levelup. This means level-mem could just do module.exports = require('memdown') to export (largely) the same functionality as before. Which begs the question, should we:

Keep memdown (as an abstract-level database); deprecate level-mem (as a levelup db)
Deprecate memdown (as an abstract-leveldown database); move code to level-mem (as an abstract-level db)
Deprecate both and create a new memory-level package (as well as leveldb-level, indexeddb-level, etc)

@Level/core thoughts?

Option 3, where *-level naming means a database and level-* means a plugin, could look like:

Old module(s)
New module

abstract-leveldown
abstract-level

memdown / level-mem
memory-level

leveldown
leveldb-level

level-js
indexeddb-level

level
level1

rocksdb / level-rocksdb
rocksdb-level

level-party
party-level

multileveldown
protobuf-level? peer-level?

subleveldown
?

level-test
test-level

encoding-down
n/a

deferred-leveldown
n/a

1 Would export leveldb-level in Node and indexeddb-level in browsers.

Keep memdown (as an abstract-level database); deprecate level-mem (as a levelup db)

Not really an option to me, when it doesn't make sense for everything to be called down.

2. Deprecate memdown (as an abstract-leveldown database); move code to level-mem (as an abstract-level db)

I think this is the best for consumers, but I wonder how we would do that. If we moved the code, we'd lose history, if we renamed the repos people might be confused.

3. Deprecate both and create a new memory-level package (as well as leveldb-level, indexeddb-level, etc)

Prefixes are nicer because they sort well 🤔

I wonder how we would do that. If we moved the code, we'd lose history, if we renamed the repos people might be confused.

The best (but indeed not perfect) way would be to rename level-mem to e.g. level-mem-archived and fork memdown to level-mem (not through github).
The potential confusion is why I'm leaning towards option 3 atm, because it makes a clean split. Consumers will have to replace their require() or import statements, which is not that bad especially if it results in a consistent set of names (which is a source of confusion today and not just because of "up" vs "down"; I'm looking at you level-js and rocksdb).

Prefixes are nicer because they sort well

It's a crowded namespace so we'd have to use an npm @level scope for that. A nice thing about the current "down" naming is that you can tell if a module is a store or a plugin; *-level naming preserves that (though again, not perfectly).

It will be confusing either way, so I'm also leaning towards option 3, to make it less confusing. New names also makes it easier to talk about different things.

To increase the benefit of new names, we could take them a bit further. For example rave-level to replace level-party.

Flashing image

I considered scopes for a bit but it doesn't help because we'll still lack unique names for repos, code variables and human communication.

As for subleveldown (though later on I want to merge that into abstract-level too) I think I'll go for prefix-level:

Click to expand
✖ sublevel (https://www.npmjs.com/package/sublevel) is unavailable
✖ level-sublevel (https://www.npmjs.com/package/level-sublevel) is unavailable
⚠ level-sub (https://www.npmjs.com/package/level-sub) is squatted
✖ sub-level (https://www.npmjs.com/package/sub-level) is unavailable
✔ sublevel-level is available
✔ namespaced-level is available
✔ namespace-level is available
✔ section-level is available
✔ sectioned-level is available
✔ prefix-level is available
✔ prefixed-level is available
✔ subspace-level is available
⚠ subspace (https://www.npmjs.com/package/subspace) is squatted
✔ spacelevel is available
✔ space-level is available

Here's a complete set of names. Unique enough, available on npm, and able to distinguish between the name of the abstract-level implementation and its underlying store (e.g. LevelDB). I think this works rather well.

Old module(s)
New module
Named export

abstract-leveldown
abstract-level
AbstractLevel

leveldown
classic-level
ClassicLevel

memdown & level-mem
memory-level
MemoryLevel

level-js
browser-level
BrowserLevel

level
level1
Level

rocksdb & level-rocksdb
rocks-level
RocksLevel

multileveldown
many-level
ManyLevel

level-party
rave-level
RaveLevel

subleveldown
prefix-level
PrefixLevel

1 Will export classic-level in Node and browser-level in browsers.

To clarify that "Named export" column, I'm also thinking of using classes and named exports everywhere. E.g.:
const { ClassicLevel } = require('classic-level')
const { MemoryLevel } = require('memory-level')

const db = new ClassicLevel('./db', { valueEncoding: 'json' })
const db = new MemoryLevel({ valueEncoding: 'json' })

This makes TypeScript typings easier (cc @MeirionHughes) as the main class can only be called in one way (with new) which is simpler to type, and the type declarations can have additional exports (that don't necessarily have a counterpart in JS) like reusable interfaces. Without messing with default exports. E.g.:
export class ClassicLevel {
  // ...
}

export interface ReadOptions {
  fillCache?: boolean | undefined
}

Closing as "resolved". If you have objections please raise them soon, because after landing https://github.com/Level/abstract-level/pull/8, I'll release abstract-level 1.0.0 and start to push new repo's - classic-level, memory-level and browser-level are code complete (what's left is mainly docs). I've been postponing benchmarks just because I'm not in the mood for that type of work (in my free time) and that's fine. I want to get this thing out the door. I'm not gonna do a prerelease round, going straight to 1.0.0 versions.


Refactor to organise code

Done: https://github.com/munir131/attachment-downloader/releases/tag/1.1.0


Any benchmark about Velox Vs Spark Executor?

Say we have TPC-H Q1, we execute this query in one process in Velox and one spark executor, do we have any benchmark result about this? Our evaluation shows that Velox is around 20x speedup over spark executor on TPC-H Q1 when executing on single node, single executor.

@eedalong  you may refer to https://github.com/oap-project/gluten#5-performance


Add Euro type

Please go the the Preview tab and select the appropriate sub-template:

Applications
Others

@Fredehagelund92 thank you for getting the ball rolling on this!! I continued this work over in PR #3850. Going to close this PR in favor of that one, we'll hopefully have this functionality available for you soon!


WIP vNext - Segmentation Changes II.

Round 2, lets go!
Note: Some naming conventions still need to be made more consistent internally.
Efficiency
On mouse down the labelmap is fetched and the reference to it cached within the tool. Whether the stroke should be additive or subtractive is also cached on the initial click (either via ctrl being pressed, or configuration.alwaysEraseOnClick being cached) .
On mouse up the labels present on the slice are cached in the labelmap2D.segmentsOnSlice object (which could probably do with a better name). This is useful, as it cheap to do for a single slice, and then when you eventually want to output this segmentation you may do so a lot quicker as you already have this info. For full body with many segmentations, dcmjs was taking up to 10 seconds to save a DICOMSEG, which is hardly good.
In the future it'd be good to draw to on a separate, smaller image and bake it into the larger image when needed, this might be quicker than redrawing the whole frame? We currently have issues with very large DX images.
API Changes:
getters

getters.metadata(elementOrEnabledElementUID, labelmapIndex, segmentIndex):

now defaults to the activeLabelmapIndex if the labelmapIndex argument isn't given.

getters.activeSegmentIndex(elementOrEnabledElementUID, labelmapIndex):

Returns the active segment segment index  for the active labelmap for the series displayed on the element.
Defaults to the activeLabelmapIndex if the labelmapIndex argument isn't given.

getters.activeLabelmapIndex(elementOrEnabledElementUID):

Returns the activeLabelmapIndex of the labelmap displayed on the element.

setters

setters.deleteSegment( elementOrEnabledElementUID, segmentIndex, labelmapIndex):

Deletes the segment from the labelmap and any associated metadata.
Defaults to the activeLabelmapIndex if the labelmapIndex argument isn't given.

TODO: For input we need to set up the segmentsOnSlices objects, this could be quite expensive for CT volumes, and should likely be done in a worker.


Revise Allen notebook

Goal: if you just clicked 'run all', it would work on fresh schema and save output to user-specific directory. This currently errors on the last cell due to restrictions on write permissions
suite2p -> sbxreader -> numpy.memmap

I attempted to resolve with edits to sbxreader but ran into issues


Unable to see mini uart /dev/ttyS0 /dev/Serial1 on CM3+

Hello,
I see this issue on poky honister and poky kirkstone on a CM3+.
The problem is that  /dev/ttyS0 is not showing up.
/dev/ttyAMA0 is working fine.
I've built a simply "core-image-minimal" system with only little modification to have a parallel display working with vc4-drm-v3d.
Adding/Removing ENABLE_UART="1" in local.conf does not change the behvoir.
dmesg doesn't tell anything about /dev/ttyS0
I have tested the same configuration with RaspberryPI OS and in that case /dev/ttyS0 is working fine.
In order to have it work, I simply add to config.txt:
force_turbo=1
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
The same config.txt does not work for meta-raspberry.
This made me think that some configuration is wrong in meta-raspberry for cm3+.
According to Raspberry pi documentation, on CM3+ mini uart should work without affecting bluetooth.

Can you please help me solve this issue? I don't know what to do anymore, I've carefully red many post but all didn't have a working  solution.
Thanks!

Looking more into this, raspi-gpio get gives:
GPIO 32: level=1 fsel=0 func=INPUT GPIO 33: level=1 fsel=0 func=INPUT
It seems that
force_turbo=1 dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
in config.txt has been ignored. Why?
Also, ENABLE_UART does not change the behavoir because I add a custom config.txt after flashing and according to meta-raspberry conf files, ENABLE _UART should only add enable_uart=1 in config.txt

Are my question bad posted? Can you please help me solving this?
I think that minuart malfunction on CM3+ can be of common interest, espacially if with raspberrypi OS is perfectly working...

As you can see there seem to be very few people using CM3+ these days. I would start by investigating the version differences between RaspberryPi OS and meta-raspberrypi. Maybe we miss some fixes?

Thank you for your reply Andrei.
I will soon follow your suggestion to try with the master branch, I have not tried yet.
I'm also trying to compare kernel .config between my distro and a Raspberry OS. I know I can get it from /proc/config.gz for raspberry OS but I don't know how to get it from a simple core-image-minimal build since that file is missing. Do you know another way to get kernel .config?

You can enable it in the kernel configuration
https://cateee.net/lkddb/web-lkddb/IKCONFIG_PROC.html

Thank you Andrei.
In order to see /proc/config.gz I simply ended up to modprobe its module with:
modprobe configs
I also performed a kernel configuration comparison, finding nothing relevant different from Raspberrypi OS.
Then I struggled to run "vcdbg log msg", since it is a propetary software and a few more libraries are needed (libdebug_sym.so.0, libelftoolchain.so, libvcos.so.0).
All this to find out that... uart1.dtbo was missing!

Thanks for your support, I close the thread.

Happy to hear you've figured it out.

@newmedFabio do you remember what error caused this problem? I also just noticed I'm missing files from the overlay directory, in particular uart1.dtbo. Thanks!

Hello Luca,
the main issoue was that /dev/ttyS0, which was the second serial interface, was missing from /dev/ folder.

Yes, that is clear. But do you remember why the uart1.dtbo file was not there? My understanding is that most dtbo files must be listed explicitly, which they are already there in Raspberry OS.

I don't know why it was not there, I suppose it has something to do with meta-raspberry choices.
Maybe it has been excluded from core-image-minimal.
To verify I used:
'
bitbake -e core-image-minimal | grep ^RPI_KERNEL_DEVICETREE_OVERLAYS
'
If it is not listed, you can add it creating a simple  linux-raspberrypi_%.bbappend and wrinting inside:
'
RPI_KERNEL_DEVICETREE_OVERLAYS:append = "
overlays/uart1.dtbo
'

Yes, that is what I did as well. Thanks.


Localize Directory names

I have a site with basic localization working fine. But when I move the pages to a directory, there is no way to localize the name of the directory. Is there any workaround for this issue?

try this: https://middlemanapp.com/advanced/localization/#localized-paths

No that's not what I was talking about!
Say for instance I have a page structure:
localizable
|--customer-engagment [directory]

Should work the exact same way

---
es:
  paths:
    "customer-engagement": "something-else"

Nope. That doesn't work, unless the core i18n extension is modified. Now, I have made the necessary changes in the i18n gem of my project, but it would be nice if it is implemented in middleman core.

Should be happening here: https://github.com/middleman/middleman/blob/v3-stable/middleman-core/lib/middleman-more/core_extensions/i18n.rb#L252
We have tests for this, will have to write some more.


Support mqtt to rpc by match topic.

Usually we need call with device by req/resp, if can support, everyone is beneficial.
Here's a scene:
/thing/down
/thing/down/reply

When configured to match and support RPC, if an RPC is called, the broker automatically adds a request_id and processes the response matching.
The device only needs to return the request_id, and the named request_id  is configurable.
Why do this in the broker?
I think doing this in the broker is faster, has lower latency, and is more cost-effective in terms of resource.

Hello, first of all, thank you for your interest in RMQTT. Regarding the business scenario you described, I am not sure if I have fully understood it: MQTT Client -> MQTT Broker -> (req) RPC (resp) -> MQTT Broker -> MQTT Client. When the mqtt broker receives a message published by the client, it calls a backend RPC service, obtains the response result, and then forwards it to the client. Is that correct?

RPC Client(req/resp) <-> MQTT Broker <-> MQTT Client, like this.

This feature is not yet supported and there are no plans to support it in the near future. Thank you again for your interest in RMQTT.


New release?

Is there a new release planned in near future? 3.1.2 is from May 2018 and master changed a lot since that

We're running into issues because we can't use 'pip freeze' without end up with a back-rev'ed version.  Please cut a new release to pypi.

@saadullahaleem, While we wait for a new release, have you considered pip installing to a specific commit version?
This will get you most recent version, 3.2 (as of this post):
pip install git+https://github.com/jazzband/django-model-utils.git@c4a252d1fb38c8fa7c645bc9292712e2fdf4d7c1#egg=django-model-utils

or drop this in your requirements.txt file:
-e git+https://github.com/jazzband/django-model-utils.git@c4a252d1fb38c8fa7c645bc9292712e2fdf4d7c1#egg=django-model-utils

Then just replace that line when the new release drops.

When we can expect new release?

It's been one year now, without new release and enough bug fixes...

Would really appreciate a PyPI release, as the latest commits add Django 2.2 support which we need. Thanks 👍


Logic error when trying to create weekly recurrences with a byDay before the current start date day

Hello Tom,
Firstly, thank-you for this great library! It is really amazing!
I've come across an error when I try and create weekly recurrences that have a BYDAY value before the day of the start date.
For example, if I try and generate recurrences with the following rule and a start date day of Wednesday, I get an exception The start date must be the first occurrence.
FREQ=WEEKLY;BYDAY=Mo;COUNT=4;

If I change BYDAY to We, Th, Fr, Sa or Su it works correctly.
Is there anyway that When can deal with this sort of scenario and continue to create the event on the following Monday?
Tim

Hey Tim,
The start date actually has to match the rules which you specify (it is the first occurrence). Therefore if you're attempting to generate occurrences which are on a Monday, the start date needs to be a Monday.
Here is a working example of your rrule.
$when = new When();
$when->startDate(new DateTime('2015-02-02'))
     ->rrule('FREQ=WEEKLY;BYDAY=MO;COUNT=4;')
     ->generateOccurrences();

echo '<pre>';
print_r($when->occurrences);
echo '</pre>';

Hi Tom,
Thank-you for getting back to me! I had feared that this was the case.
Can you think of any creative way for me to deal with the scenario of someone who wants an event to happen every monday, wednesday and friday but the first event occurs on a Friday?
Thanks for your help,
Tim

That is perfectly valid, try this:
$when->startDate(new DateTime('2015-02-06'))
     ->rrule('FREQ=WEEKLY;BYDAY=MO,WE,FR;COUNT=4;')
     ->generateOccurrences();

Hi Tom,
Well I'm feeling a little silly now, I can't reproduce it even with the rules which I noted didn't work correctly for me.
The only thing I can think of is that my start date conversion may have been faulty (I'm converting between timezones) and wasn't actually a day on which a repeat was being specified for.
Sorry about that, but thank-you very much for your assistance.
Tim

I also suffering from same issue plz give me any suggestion
Exception 'app\components\**InvalidStartDate** ' with message '**The start date must be the first occurrence**.'


Handle case when no docker-machine installed

Extend the script to check for availability of docker-machine.
If docker-machine is not found, work on the assumption that Docker
is already configured -- i.e. either the Docker Engine runs locally,
or DOCKER_xxx environment variables are defined to correctly connect
to a Docker Engine running remotely.
See also: https://docs.docker.com/engine/reference/commandline/cli/#environment-variables
Signed-off-by: Gianpaolo Macario<EMAIL_ADDRESS>

Notice that this is not quite required as docker-machine is now available for most of the OS/architecture where docker runs.
See https://docs.docker.com/machine/install-machine/

Please see https://github.com/gmacario/easy-jenkins/pull/43 instead


Question about consul service registration with regards to ports and docker

i currently have an app that is running in a docker container using mesos scheduled with marathon, along with the mesos-consul bridge.
Current marathon app configuration is using bridge networking and allowing mesos/marathon to select whatever port that is available for the host port, but the docker container itself is bound to 8080:
{
"container": {
"type": "DOCKER",
"docker": {
"image": "sarlindo/wildfly-app",
"network": "BRIDGE",
"portMappings": [
{ "containerPort": 8080, "hostPort": 0, "servicePort": 0, "protocol": "tcp" }
]
}
},
"id": "wildfly",
"cmd": "/opt/jboss/wildfly/bin/standalone.sh -b <IP_ADDRESS> -bmanagement=<IP_ADDRESS>",
"instances": 1,
"cpus": 0.3,
"mem": 256
}
Now, when this service gets registered with consul by the mesos-consul bridge, I see it being registered to the following ip/port.
<IP_ADDRESS>:31657
Now the ip here is the internal docker ip and not the host and the port number is the host port that mesos/marathon assigned.
The issue now is I can't get to this service because inside the docker container the port is actually 8080.
Is this the way this is suppose to work? Or am I doing something wrong here?

Are you using the default mesos-ip-order? Is docker included in the list? I haven't seen a use for having docker in the search order since it returns the docker IP address which isn't particularly useful as far as I can tell. If it is in the search list, try removing it.
The port is probably correct. Mesos will assign a random port to the docker container and map from 31657->8080.

Yes the port is correct, it's just the IP chosen and registered with consul was the docker IP address. I am running the mesos-consul with defaults. The following is the marathon json i am using to run the mesos-consul bridge.
{
"container": {
"type": "DOCKER",
"docker": {
"image": "ciscocloud/mesos-consul",
"network": "BRIDGE",
"parameters": [
{ "key": "rm", "value": "true" }
]
}
},
"id": "mesos-consul",
"args": ["--zk=zk://<IP_ADDRESS>:2181/mesos"],
"instances": 1,
"cpus": 0.1,
"mem": 256,
"constraints": [["hostname", "CLUSTER", "node1"]]
}

Hmm...I can't reproduce...Can you post the task section from the Mesos master? /master/state.json from the Mesos leader

Here you go below, I think I may be bumping into this issue https://github.com/mesosphere/mesos-dns/issues/334 (I know it says mesos-dns, but if you follow the thread, I believe someone is pointing to mesos as the potential issue, but I will have to dig some more) :
            {
                "executor_id": "",
                "framework_id": "13742ebd-7985-4898-b01e-6587d19b885d-0001",
                "id": "wildfly.88156cb6-925c-11e5-b212-02429beb943f",
                "name": "wildfly",
                "resources": {
                    "cpus": 0.3,
                    "disk": 0,
                    "mem": 256.0,
                    "ports": "[31268-31268]"
                },
                "slave_id": "a8f46f83-034d-459b-ac0e-e2effd094e4f-S1",
                "state": "TASK_RUNNING",
                "statuses": [
                    {
                        "container_status": {
                            "network_infos": [
                                {
                                    "ip_address": "<IP_ADDRESS>"
                                }
                            ]
                        },
                        "labels": [
                            {
                                "key": "Docker.NetworkSettings.IPAddress",
                                "value": "<IP_ADDRESS>"
                            }
                        ],
                        "state": "TASK_RUNNING",
                        "timestamp":<PHONE_NUMBER>.15899
                    }
                ]
            },

That is exactly what you're running into. Ugh. The default search order is netinfo,mesos,host so it's using the ip address in the network_infos block. A workaround is to add "--mesos-ip-order=mesos,host" to your marathon job for mesos-consul.

@ChrisAubuchon I have actually been trying this, but now it seems mesos-consul bridge won't even register any new services with consul, I created a new service in marathon and when I go to the consul ui it doesn't register anything now?
This is now my new marathon json for mesos-consul
{
"container": {
"type": "DOCKER",
"docker": {
"image": "ciscocloud/mesos-consul",
"network": "BRIDGE",
"parameters": [
{ "key": "rm", "value": "true" }
]
}
},
"id": "mesos-consul",
"args": ["--zk=zk://<IP_ADDRESS>:2181/mesos --mesos-ip-order=mesos,host"],
"instances": 1,
"cpus": 0.1,
"mem": 256,
"constraints": [["hostname", "CLUSTER", "node1"]]
}
These are the logs that I see for the mesos-consul bridge:
vagrant@node1:~/projects/consul$ sudo docker logs 5cd4ec4464d7
2015/11/24 16:26:45 Connected to <IP_ADDRESS>:2181
2015/11/24 16:26:45 Authenticated: id=94921046598942733, timeout=40000
Any clue as to why adding this new flag would cause issues?

The command line arguments in the args list need to be separated:
"args": [
  "--zk=zk://<IP_ADDRESS>:2181/mesos",
  "--mesos-ip-order=mesos,host"
  ],

oops! it's now working. thanks Chris.
Out of curiosity, do you work for cisco? what does cisco the company have to do with these projects?

Mesos-consul was developed as part of Cisco's Mantl project

thanks


Add R implementation of Brainfuck

I'm going to clean up some of the parts of this PR that are not related to the R implementation. You're misunderstanding a few things about the program.yaml file and how tests are run.
That's fair because I haven't written them down. :)

Merge this PR and you'll be good to go! https://github.com/spasticus74/tinyprograms/pull/1

Thanks Phil,
My apolgies for any inconvenience or frustration I may have caused - this is my first ever PR ...

Thanks Phil,
My apologies for any inconvenience or frustration I may have caused - this is my first ever PR ...

It's ok! You're doing great. I'm just helping along. :)

Nice work! It's live here: https://tinyprograms.org/Brainfuck/R.html


Restructuring pyxray to store data in a SQLite database

This is the pull request for issue #4.

Current coverage is 93.26% (diff: 93.26%)

Merging #7 into master will increase coverage by 18.04%

@@             master         #7   diff @@
==========================================
  Files             7         18     +11
  Lines           985       2169   +1184
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            741       2023   +1282
+ Misses          244        146     -98
  Partials          0          0

Powered by Codecov. Last update 0b2ef9e...189c250


Split Client server into two images

This pr makes the necessary changes to the client sever, after the split one contains cosign and gitsign the other contains rekor-cli and ec

@JasonPowr I don't like the concept of having two pods at all TBH. I know you have reason to do that so I am thinking about having both container running in the single pod. That would need containers to serve on different port. Would it be possible to configure it using ENV variable or so?

@JasonPowr I don't like the concept of having two pods at all TBH. I know you have reason to do that so I am thinking about having both container running in the single pod. That would need containers to serve on different port. Would it be possible to configure it using ENV variable or so?

I agree its not the nicest solution, I'm not sure if I can configure it using a Env var but ill look into it. The main reason for the separate pods is because Apache web sever automatically binds to port 8080 by default, and when running the two images in the same pod it results in a port binding error

@JasonPowr stepping back what is the why? To make the change

@JasonPowr stepping back what is the why? To make the change

@cooktheryan I believe its because the client server image got too big during TP2 and was breaking builds: https://issues.redhat.com/browse/SECURESIGN-624

@bouskaJ So I don't think there is a way I can set it up using env vars, If we don't want it running two pods I believe we may have two options
We could do something like this:
Containers: []core.Container{
	{
		Name:            cliServerName,
		Image:           image,
		ImagePullPolicy: "IfNotPresent",
		Ports: []core.ContainerPort{
			{
				ContainerPort: 8080,
				Protocol:      "TCP",
			},
		},
		Command: []string{"/bin/sh", "-c"},
		Args: []string{
			"sed -i 's/Listen <IP_ADDRESS>:8080/Listen <IP_ADDRESS>:8081/' /etc/httpd/conf/httpd.conf && run-httpd",
		},
	},
},

Or we could move the sed command to the build process of the second client server image, wdyt?

@JasonPowr stepping back what is the why? To make the change

@cooktheryan I believe its because the client server image got too big during TP2 and was breaking builds: https://issues.redhat.com/browse/SECURESIGN-624

Yes - it's not the image itself, but the source-image-build task results are too large for konflux. This is because it was including all of the source for cosign, gitsign, rekor-cli and ec. Once we added ec to the mix it went over the task result size limit, and that was not something easily fixable by the konflux team iiuc.

We could do something like this:
Containers: []core.Container{
	{
		Name:            cliServerName,
		Image:           image,
		ImagePullPolicy: "IfNotPresent",
		Ports: []core.ContainerPort{
			{
				ContainerPort: 8080,
				Protocol:      "TCP",
			},
		},
		Command: []string{"/bin/sh", "-c"},
		Args: []string{
			"sed -i 's/Listen <IP_ADDRESS>:8080/Listen <IP_ADDRESS>:8081/' /etc/httpd/conf/httpd.conf && run-httpd",
		},
	},
},

Or we could move the sed command to the build process of the second client server image, wdyt?

IMO the container should default to 8080. The reason we are having to do all of these shenanigans is because we want both servers to run from the same pod. So I think having the sed command to hack the port here in the Container command args is the right place for it. Don't forget to set ContainerPort to 8081 on that Container spec too.

We could do something like this:
Containers: []core.Container{
	{
		Name:            cliServerName,
		Image:           image,
		ImagePullPolicy: "IfNotPresent",
		Ports: []core.ContainerPort{
			{
				ContainerPort: 8080,
				Protocol:      "TCP",
			},
		},
		Command: []string{"/bin/sh", "-c"},
		Args: []string{
			"sed -i 's/Listen <IP_ADDRESS>:8080/Listen <IP_ADDRESS>:8081/' /etc/httpd/conf/httpd.conf && run-httpd",
		},
	},
},

Or we could move the sed command to the build process of the second client server image, wdyt?

IMO the container should default to 8080. The reason we are having to do all of these shenanigans is because we want both servers to run from the same pod. So I think having the sed command to hack the port here in the Container command args is the right place for it. Don't forget to set ContainerPort to 8081 on that Container spec too.

yes, I agree with @lance I would not hack the container image. I still think that having both in one pod (including the hack) is less messy than having two deployments but let's hear from others @osmman @cooktheryan WDYT?

We could do something like this:
Containers: []core.Container{
	{
		Name:            cliServerName,
		Image:           image,
		ImagePullPolicy: "IfNotPresent",
		Ports: []core.ContainerPort{
			{
				ContainerPort: 8080,
				Protocol:      "TCP",
			},
		},
		Command: []string{"/bin/sh", "-c"},
		Args: []string{
			"sed -i 's/Listen <IP_ADDRESS>:8080/Listen <IP_ADDRESS>:8081/' /etc/httpd/conf/httpd.conf && run-httpd",
		},
	},
},

Or we could move the sed command to the build process of the second client server image, wdyt?

IMO the container should default to 8080. The reason we are having to do all of these shenanigans is because we want both servers to run from the same pod. So I think having the sed command to hack the port here in the Container command args is the right place for it. Don't forget to set ContainerPort to 8081 on that Container spec too.

yes, I agree with @lance I would not hack the container image. I still think that having both in one pod (including the hack) is less messy than having two deployments but let's hear from others @osmman @cooktheryan WDYT?

Did you think about usage of sidecars? Basically to have one containers with HTTP server and sidecars with binaries

We could do something like this:
Containers: []core.Container{
	{
		Name:            cliServerName,
		Image:           image,
		ImagePullPolicy: "IfNotPresent",
		Ports: []core.ContainerPort{
			{
				ContainerPort: 8080,
				Protocol:      "TCP",
			},
		},
		Command: []string{"/bin/sh", "-c"},
		Args: []string{
			"sed -i 's/Listen <IP_ADDRESS>:8080/Listen <IP_ADDRESS>:8081/' /etc/httpd/conf/httpd.conf && run-httpd",
		},
	},
},

Or we could move the sed command to the build process of the second client server image, wdyt?

IMO the container should default to 8080. The reason we are having to do all of these shenanigans is because we want both servers to run from the same pod. So I think having the sed command to hack the port here in the Container command args is the right place for it. Don't forget to set ContainerPort to 8081 on that Container spec too.

yes, I agree with @lance I would not hack the container image. I still think that having both in one pod (including the hack) is less messy than having two deployments but let's hear from others @osmman @cooktheryan WDYT?

Did you think about usage of sidecars? Basically to have one containers with HTTP server and sidecars with binaries

Good idea @osmman I like it! Here is a nice example with nginx server https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

I would like to see if there is any way to fix this in Konflux. This seems wrong and something more folks are going to face in the future.

+1 @osmman idea that would be a very smooth way to solve this

@bouskaJ @osmman So to do this Ill need to make changes to the client-server images and remove the HTTP aspects of them, before I begin the process are you looking for something like this or am I misunderstanding?
Spec: core.PodSpec{
	Volumes: []core.Volume{
		{
			Name: "shared-data",
			VolumeSource: core.VolumeSource{
				EmptyDir: &core.EmptyDirVolumeSource{},
			},
		},
	},
	InitContainers: []core.Container{
		{
			Name:    "init-shared-data-cg",
			Image:   "quay.io/japower/client_server_test:latest",
			Command: []string{"sh", "-c", "cp -r /opt/app-root/src/clients/* /var/www/html/clients/"},
			VolumeMounts: []core.VolumeMount{
				{
					Name:      "shared-data",
					MountPath: "/var/www/html/clients/",
				},
			},
		},
		{
			Name:    "init-shared-data-re",
			Image:   "quay.io/japower/client_server_test_re:latest",
			Command: []string{"sh", "-c", "cp -r /opt/app-root/src/clients/* /var/www/html/clients/"},
			VolumeMounts: []core.VolumeMount{
				{
					Name:      "shared-data",
					MountPath: "/var/www/html/clients/",
				},
			},
		},
	},
	Containers: []core.Container{
		{
			Name:            cliServerName,
			Image:           "registry.access.redhat.com/ubi9/httpd-24@sha256:965f7b03ae8f45228bad765ce47bc8956711e854213df0e4cee8623d51317b0a",
			ImagePullPolicy: core.PullAlways,
			Ports: []core.ContainerPort{
				{
					ContainerPort: 8080,
					Protocol:      core.ProtocolTCP,
				},
			},
			VolumeMounts: []core.VolumeMount{
				{
					Name:      "shared-data",
					MountPath: "/var/www/html/clients/",
				},
			},
		},
	},
},

this is a very smooth implementation of this idea +1

/retest

/lgtm


Azure Service endpoint does not work with a proxy

What happened?
When I try :

I actually use a Azure Open AI service behind this proxy. I have my own endpoint and I use the key which is quite long. almost like a jwt token. I actually dont use the parameters there like resource, version etc. I just directly specify my endpoint

Relevant log output or stack trace
I dont know how to get the stacktrace. But I just get this error Unknown API response. Code: 200, Body:

Steps to reproduce
I can help if needed
CodeGPT version
2.2
Operating System
Windows

https://github.com/carlrobertoh/CodeGPT/issues/224#issuecomment-1757156450
Did this help ?

From now on, all custom requests must now be configured in the 'Custom OpenAI Service' configuration panel (including Azure). Please create a new ticket if you encounter any problems with this.


Facade not found after update

Hi,
I'm rather sure I'm missing something quite obvious here but can't figure it out after a few hours spent on this, seems it has to do with deferred providers but I'm not too sure :
I'm was using this amazing package v3.0, with Asset 3.6 everything was working okay until I realised it's laravel 5.7 I have installed, so I updated modules to 4.0 (and did the config update) and Asset to 3.7.
I now cannot access the Facade 'Asset' from within a boot method of my core module, error thrown is 'Class 'Asset' not found'.
The funny thing is I have another module that uses this facade in the exact same way and it works. The only difference it seems is that this module has a bigger order specified in the module.json (core is 0, all the others are 1).
core module.json :
{
    "name": "Core",
    "alias": "core",
    "description": "",
    "keywords": [],
    "active": 1,
    "order": 0,
    "providers": [
        "Orchestra\\Asset\\AssetServiceProvider",
        "Barryvdh\\Debugbar\\ServiceProvider",
        "Igaster\\LaravelTheme\\themeServiceProvider",
        "Modules\\Core\\Providers\\CoreServiceProvider"
    ],
    "aliases": {
        "Asset":"Orchestra\\Support\\Facades\\Asset",
        "Theme" : "Igaster\\LaravelTheme\\Facades\\Theme",
        "TextSnippet":"Modules\\Core\\Facades\\TextSnippet",
        "ContextualLinks":"Modules\\Core\\Facades\\ContextualLinks",
        "Notify":"Modules\\Core\\Facades\\Notify"
    },
    "files": [
        "start.php"
    ],
    "requires": []
}

I tried to clear caches, emptied the bootstrap/cache folder, changed the order of the providers in the module.json, set defer to false in the AssetServiceProvider but no luck so far.
This probably has to do with my lack of understanding of deferred providers, is there anything I do wrong here ?
Regards

I'll close this as there hasn't been a reply in a while, feel free to comment if needed.

Hi,
Didn't have time to work on this recently but I've just tried your solution and it does work, thanks !
Now I'm not totally happy with this solution as it's kind of breaking the idea of having modules declaring their own dependencies, ideally I'd like not to touch app.php and have all my providers imported in my modules, so that if one day I need to update laravel core, I can just do it, if that make sense (?).
What do you reckon, would that be related to this package ? Is this something you can help with ?
Or should I ask Orchestra Asset developers for help ?
Happy to help in any way I can.
Thank you.


Lambda Function Triggering from S3 - Help

What platform/OS are you using?
Windows 7 64bit
What compiler are you using? what version?
Visual Studio 2017
What's your CMake arguments?
cmake ../aws-sdk-cpp-1.2.20 -G "Visual Studio 15 2017 Win64" -DSIMPLE_INSTALL=OFF
-DCMAKE_INSTALL_PREFIX="../MyLibs/aws-sdk-cpp-1.2.20"
Can you provide a TRACE level log? (sanitize any sensitive information)
NA
I could do with some clarification/help with Lambdas please.  I have setup, via the AWS console, two Lambda functions. The first is triggered when any object is created in my bucket, the second when something is deleted. The Lambda functions are written in Python 2.7 and update an index in DynamoDB. This all works just fine if I set things up through the console
I'm now trying to achieve the same using the C++ SDK.  Here's what I've done:

I create a Role (let's call it Role-X) giving it a name and a policy document that allows it is to assumed by the Lambda service. I then attach the managed policies 'AmazonS3ReadOnlyAccess' and 'AmazonDynamoDBFullAccess' to allow my Lambda function to Read S3 object metadata and put items into my DynamoDB.

I create the Lambda function specifying a name, python2_7 runtime, the python code zip file etc. This succeeds and I can see my newly created function in the console. All appears good at this point but there are no triggers setup.

I'm now struggling with what to do next.  I have tried  setting up a notification configuration for my S3 bucket (using a PutBucketNotificationConfigurationRequest, LambdaFunctionConfiguration and the PutBucketNotificationConfiguration(...) API). This always fails with a 'Not authorized to invoke function' error. I can't see what I'm missing, can anyone help

Regards,
Paul

I figured it out.

Add a permission to the lambda function to allow S3 to invoke it.  Do this using the Aws::Lambda::Model::AddPermissionRequest request and LambdaClient->AddPermission(...) method.
The call to S3Client->PutBucketNotificationConfiguration() with a LambdaFunctionConfiguration now works and I see the function correctly configured in the AWS console.


How to login as local user when that user already exists in AD

Version: <IP_ADDRESS>7
OS/Distro: Oracle Linux Server release 6.9
Issue: Creating (and loggin in) a local user when that account exists on Active Directory with the same name.
Example: Assuming we have an AD user called test and the Linux System is properly joined to domain with the AssumeDefaultDomain option enabled. Then, we want to create a local user named test.
# adduser test
adduser: user 'test' already exists

--> If we stop the lwsmd service, then this first step works:
# service lwsmd stop
# adduser test
# passwd test
Changing password for user test.
New password:
BAD PASSWORD: it is too short
BAD PASSWORD: is too simple
Retype new password:
passwd: all authentication tokens updated successfully.
# service lwsmd start

# /opt/pbis/bin/find-user-by-name test
User info (Level-0):
====================
Name:              test
SID:               S-1-5-21-3949442653-2984683991-2681223523-4212
Uid:<PHONE_NUMBER>
Gid:<PHONE_NUMBER>
Gecos:             utente test x i profili
Shell:             /bin/bash
Home dir:          /home/AMM/test
Logon restriction: YES

# cat /etc/passwd | grep test
test:x:54323:54323::/home/test:/bin/bash

# getent passwd | grep test
test:x:54323:54323::/home/test:/bin/bash
test:PBIS:1931481204:1931477505:utente test x i profili:/home/AMM/test:/bin/bash

--> but, how can we log in using the local test user?
Client side:
ssh<EMAIL_ADDRESS>Password:
Password:

Server side:
# tail -f /var/log/messages
Aug  1 14:41:08 xorasrv-pcon1 lsass: [LwKrb5GetTgtImpl /builder/src-git/Platform/src/linux/lwadvapi/threaded/krbtgt.c:346] KRB5 Error code: -1765328360 (Message: Preauthentication failed)
Aug  1 14:41:08 xorasrv-pcon1 lsass: [lsass] Failed to authenticate user (name = 'test') -> error = 40022, symbol = LW_ERROR_PASSWORD_MISMATCH, client pid = 78846

# tail -f /var/log/secure
Aug  1 14:39:33 xorasrv-pcon1 passwd: pam_unix(passwd:chauthtok): password changed for test
Aug  1 14:41:08 xorasrv-pcon1 sshd[58694]: [lsass-pam] [module:pam_lsass]pam_sm_authenticate error [login:test][error code:40056]
Aug  1 14:41:08 xorasrv-pcon1 sshd[58688]: error: PAM: Authentication failure for test from <IP_ADDRESS>

Is there any way to explicit the local user when logging in? For instance, something like the following:
ssh<EMAIL_ADDRESS>
Furthermore, shouldn't the system automatically switch to pam_unix.so if pam_lsass.so fails? Indeed, on a Ubuntu Server System the login process (replicating the same issue) properly works... It switches to pam_unix.so when pam_lsass.so doesn't find any correspondence.
Below the pam configuration files related to ssh of the two different systems.
Ubuntu Linux System:
# cat /etc/pam.d/common-auth --> called by /etc/pam.d/sshd
auth    [success=2 default=ignore]      pam_lsass.so smartcard
auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass
auth    requisite
auth    required

Oracle Linux System:
# cat /etc/pam.d/password-auth --> called by /etc/pam.d/sshd
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        requisite    pam_lsass.so    smartcard_prompt    try_first_pass
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient      pam_lsass.so      try_first_pass
auth        required      pam_deny.so

account     required      pam_lsass.so      unknown_ok
account     sufficient      pam_lsass.so
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    sufficient     pam_lsass.so
password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=2 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     sufficient      pam_lsass.so

Try adding user test to /etc/pbis/user-ignore


Support node require, fetch, and promises

Not sure if this got deleted or if I forgot to make a PR, anyways, I'd love to hear any feedback you have. I had prettier on in my editor, but I can undo the style changes if that is a problem.

@brysgo looks great. Couple of quick things:

Assume you ran the tests - can you confirm that 😄
Are you happy to license under MIT?

@rufuspollock

did not run the tests (just put together a simple use case but probably should have run them)

I will run the tests and get back to you.

Happy to license under MIT

@rufuspollock - now the tests pass ;-)

@brysgo awesome and thank-you. If you want to do a (separate) PR to add yourself as a contributor to the README please do 😄


docker-zabbix-sender not sending stats at all.

Hi,
I have been able to build and install the docker-zabbix-sender. but I an failing at the last point where I need to send stats to my remote zabbix server.
I am running docker-zabbix-sender on a bare metal.  See stack trace below
docker-zabbix-sender -v -c /etc/zabbix/zabbix_agentd.conf -z <IP_ADDRESS> -s zab_server02
2015-11-16 19:32:52,778 INFO     end-point Registered metrics entrypoint 'container-count'
2015-11-16 19:32:52,779 INFO     end-point Registered metrics entrypoint 'container-ip'
2015-11-16 19:32:52,779 INFO     end-point Registered metrics entrypoint 'cpu-count'
1
Traceback (most recent call last):
File "/usr/bin/docker-zabbix-sender", line 9, in
load_entry_point('docker-zabbix-sender==0.3.3', 'console_scripts', 'docker-zabbix-sender')()
File "/usr/lib/python2.7/site-packages/docker_zabbix_sender-0.3.3-py2.7.egg/docker_zabbix_sender/zabbix_sender.py", line 201, in run
verbose=args.verbose if args.verbose is not None else 0
File "/usr/lib/python2.7/site-packages/docker_zabbix_sender-0.3.3-py2.7.egg/docker_zabbix_sender/zabbix_sender.py", line 109, in init
**kwargs
File "/usr/lib/python2.7/site-packages/docker_zabbix_sender-0.3.3-py2.7.egg/docker_zabbix_sender/zabbix_sender.py", line 23, in init
subprocess.Popen.init(self, ZabbixSenderProcess.cmdline(**kwargs), stdin=subprocess.PIPE)
File "/usr/lib64/python2.7/subprocess.py", line 711, in init
errread, errwrite)
File "/usr/lib64/python2.7/subprocess.py", line 1308, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
zab_server02 being the hostname where the agent and docker images are running off.
I am not sure how to resolve this error. Any assistance will be highly appreciated.

Hi @interInt
The error message suggests that zabbix_sender executable, part of Zabbix, cannot be found by docker-zabbix-sender.
Maybe it zabbix_sender is not installed installed, or unavailable in the PATH environment variable given to docker-zabbix-sender. Can you please check this ?

Thank you for the feedback @tristan0x
I can confirm zabbix_sender is installed.
How can I check the path environment for docker-zabbix-sender?

From the environment (shell in terminal or the script from which your are launching docker-zabbix-sender, can you give me the output of:
echo $PATH
type zabbix_sender

I was able to run the command
echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
thereafter, I created a soft link to the path, and it was able to start
ln -s /opt/zabbix/agent/bin/zabbix_sender /usr/local/bin/zabbix_sender
docker-zabbix-sender -v -c /etc/zabbix/zabbix_agentd.conf -z <IP_ADDRESS> -s zab_server02
2015-11-17 23:35:41,475 INFO     end-point Registered metrics entrypoint 'container-count'
2015-11-17 23:35:41,475 INFO     end-point Registered metrics entrypoint 'container-ip'
2015-11-17 23:35:41,475 INFO     end-point Registered metrics entrypoint 'cpu-count'
2
2015-11-17 23:35:41,485 INFO     stats-emitter Monitoring activity of container: 3443a790cf3a890899aa656d4f50b9085b2c6a00499765ff29520411e723977b


OAK-10715 : embedded verification should use traversed nodeState

@Joscorbe , @rishabhdaim , this is more FYI as we should first merge OAK-10688 (and then I'd redo this PR from DetailedGC directly)

Replaced by https://github.com/apache/jackrabbit-oak/pull/1377


Filtered views use the base view title on the diagram, rather than the defined title

Description
I noticed something funny about filtered views: When I define a different title for a filtered view (for a system context in my case), that title is shown correctly in the diagram overview and the sidebar. However, on the diagram itself, the base diagram title is shown.
Steps to reproduce

Define a view in the DSL
Define a filtered view on top of that view with a title element (see code below)
Visualize workspace by running lite, pushing to on-premises or cloud
Look at the filtered view

Screenshot

Code sample
workspace {

   model {
      user = person "User" "A user of my software system."
      softwareSystem = softwareSystem "Software System" "My software system."

      user -> softwareSystem "Uses"
   }

   views {
      systemContext softwareSystem "SystemContext" {
         include *
         autoLayout
         title "Short Title"
         description "Such a nice description."
      }

      filtered "SystemContext" include "Element" "FilteredContext" {
         title "Much longer Title"
         description "Definitely an ugly description."
      }

      styles {
         element "Software System" {
            background #1168bd
            color #ffffff
         }
         element "Person" {
            shape person
            background #08427b
            color #ffffff
         }
      }
   }

}

Configuration
structurizr/lite:latest (Docker image pulled today)
Severity
Minor
Priority
Low
Resolution
I have no budget and there's no rush, please fix this for free
More information
No response

Fantastic, thank you for the quick fix!


Fastlane gradle task crashes on GCP build (Docker)

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
I want to deploy my android on with fastlane on an preconfigured docker with fastlane and bundler on GCP build.
But when I want to use Fastlane, it crashes on the gradle command. 😕
Command executed
bundle exec fastlane alpha
Complete output when running fastlane, including the stack trace and command used

[15:05:24]: It seems like you wanted to load some plugins, however they couldn't be loaded
[15:05:24]: Please follow the troubleshooting guide: https://docs.fastlane.tools/plugins/plugins-troubleshooting/
[15:05:24]: ------------------------------
[15:05:24]: --- Step: default_platform ---
[15:05:24]: ------------------------------
[15:05:24]: Driving the lane 'android alpha' 🚀
[15:05:24]: ----------------------------------------
[15:05:24]: --- Step: changelog_from_git_commits ---
[15:05:24]: ----------------------------------------
[15:05:24]: $ git rev-list --tags --max-count\=1
[15:05:24]: Collecting Git commits between  and HEAD
15:05:24: --- Step: bundleRelease ---
15:05:24: ---------------------------
15:05:24: $ /workspace/android/gradlew bundleRelease -p /workspace/android
+-------------------+---------------+
|           Lane Context            |
+-------------------+---------------+
| DEFAULT_PLATFORM  | android       |
| PLATFORM_NAME     | android       |
| LANE_NAME         | android alpha |
| FL_CHANGELOG      |               |
| GRADLE_BUILD_TYPE | Release       |
+-------------------+---------------+
15:05:24: Permission denied - /workspace/android/gradlew
+------+------------------------+-------------+
|              fastlane summary               |
+------+------------------------+-------------+
| Step | Action                 | Time (in s) |
+------+------------------------+-------------+
| 1    | default_platform       | 0           |
| 2    | changelog_from_git_co  | 0           |
|      | mmits                  |             |
| 💥   | bundleRelease          | 0           |
+------+------------------------+-------------+
15:05:24: fastlane finished with errors
Looking for related GitHub issues on fastlane/fastlane...
Found no similar issues. To create a new issue, please visit:
https://github.com/fastlane/fastlane/issues/new
Run fastlane env to append the fastlane environment to your issue
bundler: failed to load command: fastlane (/usr/bin/fastlane)
/usr/lib/ruby/2.7.0/open3.rb:213:in spawn': \e[31m[!] Permission denied - /workspace/android/gradlew\e[0m (Errno::EACCES) 	from /usr/lib/ruby/2.7.0/open3.rb:213:in popen_run'
from /usr/lib/ruby/2.7.0/open3.rb:208:in popen2e' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/helper/sh_helper.rb:54:in sh_control_output'
from /usr/lib/ruby/2.7.0/forwardable.rb:235:in sh' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/helper/gradle_helper.rb:32:in trigger'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/actions/gradle.rb:60:in run' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/runner.rb:263:in block (2 levels) in execute_action'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/actions/actions_helper.rb:69:in execute_action' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/runner.rb:255:in block in execute_action'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/runner.rb:229:in chdir' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/runner.rb:229:in execute_action'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/runner.rb:157:in trigger_action_by_name' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/fast_file.rb:159:in method_missing'
from Fastfile:28:in block (2 levels) in parsing_binding' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/lane.rb:33:in call'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/runner.rb:49:in block in execute' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/runner.rb:45:in chdir'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/runner.rb:45:in execute' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/lane_manager.rb:47:in cruise_lane'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/command_line_handler.rb:36:in handle' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/commands_generator.rb:108:in block (2 levels) in run'
from /usr/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:178:in call' 	from /usr/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:153:in run'
from /usr/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/runner.rb:476:in run_active_command' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:76:in run!'
from /usr/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/delegates.rb:15:in run!' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/commands_generator.rb:352:in run'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/commands_generator.rb:41:in start' 	from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/fastlane/lib/fastlane/cli_tools_distributor.rb:122:in take_off'
from /usr/lib/ruby/gems/2.7.0/gems/fastlane-2.178.0/bin/fastlane:23:in <top (required)>' 	from /usr/bin/fastlane:23:in load'
from /usr/bin/fastlane:23:in <top (required)>' 	from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/cli/exec.rb:63:in load'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/cli/exec.rb:63:in kernel_load' 	from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/cli/exec.rb:28:in run'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/cli.rb:494:in exec' 	from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/vendor/thor/lib/thor/command.rb:27:in run'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in invoke_command' 	from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/vendor/thor/lib/thor.rb:392:in dispatch'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/cli.rb:30:in dispatch' 	from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/vendor/thor/lib/thor/base.rb:485:in start'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/cli.rb:24:in start' 	from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/exe/bundle:49:in block in <top (required)>'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/lib/bundler/friendly_errors.rb:130:in with_friendly_errors' 	from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.14/exe/bundle:37:in <top (required)>'
from /usr/bin/bundle:23:in load' 	from /usr/bin/bundle:23:in '

Environment
✅ fastlane environment ✅
Stack

Key
Value

OS
Linux fa30b99e24dc 5.4.0-1036-gcp #39~18.04.1-Ubuntu SMP Sun Jan 17 11:08:21 UTC 2021 x86_64 Linux

Ruby
2.7.2

Bundler?
true

Git
git version 2.30.2

Installation Source
/usr/bin/fastlane

Host
Linux fa30b99e24dc 5.4.0-1036-gcp #39~18.04.1-Ubuntu SMP Sun Jan 17 11:08:21 UTC 2021 x86_64 Linux (5.4.0-1036-gcp)

Ruby Lib Dir
/usr/lib

OpenSSL Version
OpenSSL 1.1.1i  8 Dec 2020

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

System Locale

Variable
Value

LANG
C.UTF-8
✅

LC_ALL

LANGUAGE

fastlane files:
`./fastlane/Fastfile`
# This file contains the fastlane.tools configuration
# You can find the documentation at https://docs.fastlane.tools
#
# For a list of all available actions, check out
#
#     https://docs.fastlane.tools/actions
#
# For a list of all available plugins, check out
#
#     https://docs.fastlane.tools/plugins/available-plugins
#

# Uncomment the line if you want fastlane to automatically update itself
# update_fastlane

default_platform(:android)

platform :android do
  desc "Runs all the tests"
  lane :test do
    gradle(task: "test")
  end

  desc "Submit a new Internal test Build the Google play"
  lane :alpha do
    changelog_from_git_commits

    gradle(
      project_dir: '/workspace/android',
      gradle_path: 'gradlew',
      task: 'bundle',
      build_type: 'Release'
    )

    upload_to_play_store(
      track: 'alpha'
      # release_status: 'draft'
    )

    # gradle(task: "clean assembleRelease")
    # crashlytics

    # sh "your_script.sh"
    # You can also use other beta testing services here
  end

  desc "Submit a new Beta Build to Crashlytics Beta"
  lane :beta do
    changelog_from_git_commits

    gradle(
      task: 'bundle',
      build_type: 'Release'
    )
    upload_to_play_store(track: 'beta')

    # gradle(task: "clean assembleRelease")
    # crashlytics

    # sh "your_script.sh"
    # You can also use other beta testing services here
  end

  desc "Deploy a new version to the Google Play"
  lane :deploy do
    gradle(task: "clean assembleRelease")
    upload_to_play_store
  end
end

`./fastlane/Appfile`
json_key_file("gc_keys.json") # Path to the json secret file - Follow https://docs.fastlane.tools/actions/supply/#setup to get one
package_name("com.gamifaction.twinty") # e.g. com.krausefx.app

fastlane gems

Gem
Version
Update-Status

fastlane
2.178.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

did_you_mean
1.5.0

bundler
2.2.14

uri
0.10.1

rake
13.0.3

CFPropertyList
3.0.3

public_suffix
4.0.6

addressable
2.7.0

artifactory
3.0.15

atomos
0.1.3

aws-eventstream
1.1.1

aws-partitions
1.433.0

aws-sigv4
1.2.3

jmespath
1.4.0

aws-sdk-core
3.113.0

aws-sdk-kms
1.43.0

aws-sdk-s3
1.91.0

babosa
1.0.4

claide
1.0.3

colored
1.2

colored2
3.1.2

highline
1.7.10

commander-fastlane
4.4.6

declarative
0.0.20

declarative-option
0.1.0

digest-crc
0.6.3

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

dotenv
2.7.6

emoji_regex
3.2.2

excon
0.79.0

faraday-net_http
1.0.1

multipart-post
2.0.0

ruby2_keywords
0.0.4

faraday
1.3.0

http-cookie
1.0.3

faraday-cookie_jar
0.0.7

faraday_middleware
1.0.0

fastimage
2.2.3

gh_inspector
1.1.3

jwt
2.2.2

memoist
0.16.2

multi_json
1.15.0

os
1.1.1

signet
0.15.0

googleauth
0.16.0

httpclient
2.8.3

mini_mime
1.0.2

uber
0.1.0

representable
3.0.4

retriable
3.1.2

google-api-client
0.38.0

rexml
3.2.4

webrick
1.7.0

google-apis-core
0.3.0

google-apis-iamcredentials_v1
0.2.0

google-apis-storage_v1
0.3.0

google-cloud-env
1.5.0

google-cloud-errors
1.1.0

google-cloud-core
1.6.0

google-cloud-storage
1.31.0

json
2.5.1

mini_magick
4.11.0

naturally
2.2.1

plist
3.6.0

rubyzip
2.3.0

security
0.1.3

simctl
1.6.8

slack-notifier
2.3.2

terminal-notifier
2.0.0

unicode-display_width
1.7.0

terminal-table
1.8.0

tty-screen
0.8.1

tty-cursor
0.7.1

tty-spinner
0.9.3

word_wrap
1.0.0

nanaimo
0.3.0

xcodeproj
1.19.0

rouge
2.0.7

xcpretty
0.3.0

xcpretty-travis-formatter
1.0.1

generated on: 2021-03-21

[15:05:21]: Take notice that this output may contain sensitive information, or simply information that you don't want to make public.
[15:05:21]: Open https://github.com/fastlane/fastlane/issues/new to submit a new issue ✅

OK, solution found... I ignored that GCP build disabled automatically the execution rights...
Just have to add the step:
name: <YOUR IMAGE>
args: ["bash", "-c", "chmod +x gradlew"]
dir: <ANDROID PROJECT PATH>
Sorry for the disturbance...


Consider adding a ports debugger command

If someone is surprised by the ports taken up on their machine, we may be able to simplify discovering what's running there.

This is outside the scope of takeout. We just need to check if the port is in use, which has since been included.


Replace TypeScript build step with Rollup.

This allows us to bundle third party dependencies into the main bundle.
Also removed tsft, as it wasn’t much use.
PAIR=SirVer

@thomasschiwietz ptal and merge if happy.

@wally-the-cartographer merge

Merge requested by authorized user thomasschiwietz. Merge queue now has a length of 1.


Error: AnimateSharedLayout is deprecated

Hello,
I use react-email in a Next.js project with the latest framer-motion installed.
When I run email dev, I receive the following error on http://localhost:3000:

Unhandled Runtime Error
Error: AnimateSharedLayout is deprecated: https://www.framer.com/docs/guide-upgrade/##shared-layout-animations
Call Stack
invariant
node_modules/framer-motion/dist/es/utils/errors.mjs (13:0)
eval
node_modules/framer-motion/dist/es/components/AnimateSharedLayout.mjs (9:17)
[...]

AnimateSharedLayout is used by react-email for its preview.
Strangely enough, when I check the version of framer-motion inside .react-email/package.json, it gets overwritten to the newest version used by my own Next.js app inside the project roots package.json.
When I manually set the version back to 8.4.6 in .react-email/package.json and run npm install && npm update in my project root, the specified version gets rewritten to the one from my own project.
The same behavior seems to be happening with any other package thats used by react-email and my project.
Any ideas?

Can you double check if you're using the latest version of react email? We recently had a PRthat changed that

Going to close since we didn't hear it back


MultiScaleDeformableAttention import error

I'm using Python 3.8 with PyTorch 1.9 and Cuda 11.1. I have already set cuda_home as such:
export CUDA_HOME=/mnt/slurm_home/remelias/anaconda3/envs/vita30/
cd /mnt/slurm_home/remelias/MeViS-main/mask2former/modeling/pixel_decoder/ops/
sh make.sh
I'm still getting MSDA import error.
Traceback (most recent call last):
line 22, in
import MultiScaleDeformableAttention as MSDA
ImportError: /mnt/slurm_home/remelias/anaconda3/envs/vita30/lib/python3.8/site-packages/MultiScaleDeformableAttention-1.0-py3.8-linux-x86_64.egg/MultiScaleDeformableAttention.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZNK2at10TensorBase8data_ptrIdEEPT_v
How can I resolve this?

It maybe a Pytorch-CUDA version mismatch problem (see here). You may upgrade your PyTorch to 2.0. Our code is based on PyTorch2.0.1+cu117.

Thank you. Using PyTorch 2.0.1+cu117 resolved the error.


update-event-schema-for-azure-storage-event-grid-notification-for-cr…

…eate-delete-directory-and-rename-blob-directory
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: wanha-ms sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

Hi Kalyana,
I’ve pushed changes for this PR according to your PR review. Could you please take a look again whenever you had some time?
https://github.com/Azure/azure-rest-api-specs/pull/7509/files
Thank you!
Best Regards
Hao Wang
From: J. Kalyana Sundaram<EMAIL_ADDRESS>Sent: Tuesday, October 15, 2019 6:11 PM
To: Azure/azure-rest-api-specs<EMAIL_ADDRESS>Cc: Hao Wang<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
@kalyanaj requested changes on this pull request.
I have added my feedback, can you please take a look?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%3Femail_source%3Dnotifications%26email_token%3DANP5OWL4KQDVMBALEO3UTY3QOZS2NA5CNFSM4JBECDZKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCICF32Y%23pullrequestreview-302276075&data=02|01|wanha%40microsoft.com|020d59d36aaf4d40bbd908d751d5b6d8|72f988bf86f141af91ab2d7cd011db47|1|0|637067850646795173&sdata=uYpnfFaIoM68sbbWa5QQzEsPqFUZr6y%2B339b3QFuodc%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANP5OWPBGPYUW7DVYCR7UV3QOZS2NANCNFSM4JBECDZA&data=02|01|wanha%40microsoft.com|020d59d36aaf4d40bbd908d751d5b6d8|72f988bf86f141af91ab2d7cd011db47|1|0|637067850646795173&sdata=vYYVidLSkgefyk%2BBbdGjhnjLgyJwgkkzC%2FE1Ug0D%2FlI%3D&reserved=0.

Adding @J. Kalyana<EMAIL_ADDRESS>explicitly here.
Also adding folks from the team for additional eyes.
Thanks.

From: Hao Wang<EMAIL_ADDRESS>Sent: Wednesday, October 16, 2019 6:14 PM
To: Azure/azure-rest-api-specs<EMAIL_ADDRESS>Azure/azure-rest-api-specs<EMAIL_ADDRESS>Cc: Author<EMAIL_ADDRESS>Ramy Wassef<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Hi Kalyana,
I’ve pushed changes for this PR according to your PR review. Could you please take a look again whenever you had some time?
https://github.com/Azure/azure-rest-api-specs/pull/7509/fileshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%2Ffiles&data=02|01|ramyw%40microsoft.com|519c0a0c241f4817c99f08d7529f4f80|72f988bf86f141af91ab2d7cd011db47|1|0|637068716492518197&sdata=XxO%2BqZb3esRBhKJMzNrUh0Z7aSxaeD9S6Rnn4UwJuEY%3D&reserved=0
Thank you!
Best Regards
Hao Wang
From: J. Kalyana Sundaram<EMAIL_ADDRESS>Sent: Tuesday, October 15, 2019 6:11 PM
To: Azure/azure-rest-api-specs<EMAIL_ADDRESS>Cc: Hao Wang<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
@kalyanaj requested changes on this pull request.
I have added my feedback, can you please take a look?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%3Femail_source%3Dnotifications%26email_token%3DANP5OWL4KQDVMBALEO3UTY3QOZS2NA5CNFSM4JBECDZKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCICF32Y%23pullrequestreview-302276075&data=02|01|ramyw%40microsoft.com|519c0a0c241f4817c99f08d7529f4f80|72f988bf86f141af91ab2d7cd011db47|1|0|637068716492528182&sdata=sGq1vMbzTYL%2F308P%2FYbQNvbVBhSkLfsp%2F6so9GzpLqM%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANP5OWPBGPYUW7DVYCR7UV3QOZS2NANCNFSM4JBECDZA&data=02|01|ramyw%40microsoft.com|519c0a0c241f4817c99f08d7529f4f80|72f988bf86f141af91ab2d7cd011db47|1|0|637068716492528182&sdata=knwEP169zCxA0ay9uoY5jphEW3PlZ7Pd9oJa%2Fd3fQFI%3D&reserved=0.

Hi all,
It looks like PR has been approved, all checks has passed. It seems I couldn’t merge the branch to master due to “You’re not authorizedhttps://help.github.com/articles/about-protected-branches/ to merge this pull request.” Could someone help me out with the merge?
https://github.com/Azure/azure-rest-api-specs/pull/7509
Thanks
Best Regards
Hao Wang
From: Ramy Wassef<EMAIL_ADDRESS>Sent: Thursday, October 17, 2019 8:49 AM
To: Hao Wang<EMAIL_ADDRESS>Azure/azure-rest-api-specs<EMAIL_ADDRESS>Azure/azure-rest-api-specs<EMAIL_ADDRESS>J. Kalyana Sundaram<EMAIL_ADDRESS>Cc: Author<EMAIL_ADDRESS>Vamshi Konagari<EMAIL_ADDRESS>Kai Hsu<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Adding @J. Kalyana<EMAIL_ADDRESS>explicitly here.
Also adding folks from the team for additional eyes.
Thanks.

From: Hao Wang <wanha<EMAIL_ADDRESS>Sent: Wednesday, October 16, 2019 6:14 PM
To: Azure/azure-rest-api-specs <reply<EMAIL_ADDRESS>Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>Cc: Author <author<EMAIL_ADDRESS>Ramy Wassef <ramyw<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Hi Kalyana,
I’ve pushed changes for this PR according to your PR review. Could you please take a look again whenever you had some time?
https://github.com/Azure/azure-rest-api-specs/pull/7509/fileshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%2Ffiles&data=02|01|wanha%40microsoft.com|9c3542d7aa6448eb92a108d7531982db|72f988bf86f141af91ab2d7cd011db47|1|0|637069241606904562&sdata=b05Em8wYlbeiwbALitxIo5SNzy8rwybODP57MeTWjwA%3D&reserved=0
Thank you!
Best Regards
Hao Wang
From: J. Kalyana Sundaram <notifications<EMAIL_ADDRESS>Sent: Tuesday, October 15, 2019 6:11 PM
To: Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>Cc: Hao Wang <wanha<EMAIL_ADDRESS>Author <author<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
@kalyanaj requested changes on this pull request.
I have added my feedback, can you please take a look?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%3Femail_source%3Dnotifications%26email_token%3DANP5OWL4KQDVMBALEO3UTY3QOZS2NA5CNFSM4JBECDZKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCICF32Y%23pullrequestreview-302276075&data=02|01|wanha%40microsoft.com|9c3542d7aa6448eb92a108d7531982db|72f988bf86f141af91ab2d7cd011db47|1|0|637069241606904562&sdata=Tj1b15f%2FklQIRxt%2BraVYeCPZRZ4XKEVdXmZnJUS9Z%2FA%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANP5OWPBGPYUW7DVYCR7UV3QOZS2NANCNFSM4JBECDZA&data=02|01|wanha%40microsoft.com|9c3542d7aa6448eb92a108d7531982db|72f988bf86f141af91ab2d7cd011db47|1|0|637069241606914515&sdata=BHw1mYQO7xMoRaRlOo4i0pGG92Ru0bA%2F7nL5v9dDcbM%3D&reserved=0.

I checked the history of this file, but couldn’t figure out who I could ping for the SDK team’s approval. Could someone help me with this?
Thank you
Best Regards
Hao Wang
From: J. Kalyana Sundaram<EMAIL_ADDRESS>Sent: Thursday, October 17, 2019 11:36 AM
To: Hao Wang<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
You will need the SDK team’s approval as well and once they approve it they will merge it.
From: Hao Wang <wanha<EMAIL_ADDRESS>Sent: Thursday, October 17, 2019 11:14 AM
To: Ramy Wassef <ramyw<EMAIL_ADDRESS>Azure/azure-rest-api-specs <reply<EMAIL_ADDRESS>Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>J. Kalyana Sundaram <kalyanaj<EMAIL_ADDRESS>Cc: Author <author<EMAIL_ADDRESS>Vamshi Konagari <Vamshi.Konagari<EMAIL_ADDRESS>Kai Hsu <kaihsu<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Hi all,
It looks like PR has been approved, all checks has passed. It seems I couldn’t merge the branch to master due to “You’re not authorizedhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-protected-branches%2F&data=02|01|wanha%40microsoft.com|860d0210359f4ed1c85408d75330d34a|72f988bf86f141af91ab2d7cd011db47|1|0|637069341470911811&sdata=I3nSIZbbOE2oYsQrFDXkYuq9Wh4v5mggP5IZuzpuXtc%3D&reserved=0 to merge this pull request.” Could someone help me out with the merge?
https://github.com/Azure/azure-rest-api-specs/pull/7509https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509&data=02|01|wanha%40microsoft.com|860d0210359f4ed1c85408d75330d34a|72f988bf86f141af91ab2d7cd011db47|1|0|637069341470921768&sdata=tHUlKj%2Bb9qT7PMiZXxxpF%2FZoYf01NkDqvZ3Op90OVEk%3D&reserved=0
Thanks
Best Regards
Hao Wang
From: Ramy Wassef <ramyw<EMAIL_ADDRESS>Sent: Thursday, October 17, 2019 8:49 AM
To: Hao Wang <wanha<EMAIL_ADDRESS>Azure/azure-rest-api-specs <reply<EMAIL_ADDRESS>Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>J. Kalyana Sundaram <kalyanaj<EMAIL_ADDRESS>Cc: Author <author<EMAIL_ADDRESS>Vamshi Konagari <Vamshi.Konagari<EMAIL_ADDRESS>Kai Hsu <kaihsu<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Adding @J. Kalyana<EMAIL_ADDRESS>explicitly here.
Also adding folks from the team for additional eyes.
Thanks.

From: Hao Wang <wanha<EMAIL_ADDRESS>Sent: Wednesday, October 16, 2019 6:14 PM
To: Azure/azure-rest-api-specs <reply<EMAIL_ADDRESS>Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>Cc: Author <author<EMAIL_ADDRESS>Ramy Wassef <ramyw<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Hi Kalyana,
I’ve pushed changes for this PR according to your PR review. Could you please take a look again whenever you had some time?
https://github.com/Azure/azure-rest-api-specs/pull/7509/fileshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%2Ffiles&data=02|01|wanha%40microsoft.com|860d0210359f4ed1c85408d75330d34a|72f988bf86f141af91ab2d7cd011db47|1|0|637069341470921768&sdata=GO2O2KcSbwmcS0jMP4LQFAfj8nRtUxpDKzgNa98QzL0%3D&reserved=0
Thank you!
Best Regards
Hao Wang
From: J. Kalyana Sundaram <notifications<EMAIL_ADDRESS>Sent: Tuesday, October 15, 2019 6:11 PM
To: Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>Cc: Hao Wang <wanha<EMAIL_ADDRESS>Author <author<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
@kalyanaj requested changes on this pull request.
I have added my feedback, can you please take a look?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%3Femail_source%3Dnotifications%26email_token%3DANP5OWL4KQDVMBALEO3UTY3QOZS2NA5CNFSM4JBECDZKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCICF32Y%23pullrequestreview-302276075&data=02|01|wanha%40microsoft.com|860d0210359f4ed1c85408d75330d34a|72f988bf86f141af91ab2d7cd011db47|1|0|637069341470931721&sdata=Zbw%2B78voYiXQeY%2BSv0ZRhL48MU5BZdk4rZPWEuGgMrY%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANP5OWPBGPYUW7DVYCR7UV3QOZS2NANCNFSM4JBECDZA&data=02|01|wanha%40microsoft.com|860d0210359f4ed1c85408d75330d34a|72f988bf86f141af91ab2d7cd011db47|1|0|637069341470931721&sdata=U5I9JRBddmY4BCMmtuC51VkRTePQeYcQkkiw%2BrbNnoo%3D&reserved=0.

Adding @Fan<EMAIL_ADDRESS>from the SDK team.
Thanks,
Kalyan
From: Hao Wang<EMAIL_ADDRESS>Sent: Thursday, October 17, 2019 11:53 AM
To: J. Kalyana Sundaram<EMAIL_ADDRESS>Ramy Wassef<EMAIL_ADDRESS>Azure/azure-rest-api-specs<EMAIL_ADDRESS>Azure/azure-rest-api-specs<EMAIL_ADDRESS>Cc: Vamshi Konagari<EMAIL_ADDRESS>Kai Hsu<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
I checked the history of this file, but couldn’t figure out who I could ping for the SDK team’s approval. Could someone help me with this?
Thank you
Best Regards
Hao Wang
From: J. Kalyana Sundaram <kalyanaj<EMAIL_ADDRESS>Sent: Thursday, October 17, 2019 11:36 AM
To: Hao Wang <wanha<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
You will need the SDK team’s approval as well and once they approve it they will merge it.
From: Hao Wang <wanha<EMAIL_ADDRESS>Sent: Thursday, October 17, 2019 11:14 AM
To: Ramy Wassef <ramyw<EMAIL_ADDRESS>Azure/azure-rest-api-specs <reply<EMAIL_ADDRESS>Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>J. Kalyana Sundaram <kalyanaj<EMAIL_ADDRESS>Cc: Author <author<EMAIL_ADDRESS>Vamshi Konagari <Vamshi.Konagari<EMAIL_ADDRESS>Kai Hsu <kaihsu<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Hi all,
It looks like PR has been approved, all checks has passed. It seems I couldn’t merge the branch to master due to “You’re not authorizedhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhelp.github.com%2Farticles%2Fabout-protected-branches%2F&data=02|01|kalyanaj%40microsoft.com|5d58145e34584e54c30608d7533337cf|72f988bf86f141af91ab2d7cd011db47|1|0|637069351747209428&sdata=01RtosXXfbV5G8o29OYwnz4gfLg4s1hNYEIpNhIH1JY%3D&reserved=0 to merge this pull request.” Could someone help me out with the merge?
https://github.com/Azure/azure-rest-api-specs/pull/7509https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509&data=02|01|kalyanaj%40microsoft.com|5d58145e34584e54c30608d7533337cf|72f988bf86f141af91ab2d7cd011db47|1|0|637069351747209428&sdata=SL9NwGqlwCiuAbWlS6V9hntZMrUIJ3ogm%2BM%2BSNfVcLY%3D&reserved=0
Thanks
Best Regards
Hao Wang
From: Ramy Wassef <ramyw<EMAIL_ADDRESS>Sent: Thursday, October 17, 2019 8:49 AM
To: Hao Wang <wanha<EMAIL_ADDRESS>Azure/azure-rest-api-specs <reply<EMAIL_ADDRESS>Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>J. Kalyana Sundaram <kalyanaj<EMAIL_ADDRESS>Cc: Author <author<EMAIL_ADDRESS>Vamshi Konagari <Vamshi.Konagari<EMAIL_ADDRESS>Kai Hsu <kaihsu<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Adding @J. Kalyana<EMAIL_ADDRESS>explicitly here.
Also adding folks from the team for additional eyes.
Thanks.

From: Hao Wang <wanha<EMAIL_ADDRESS>Sent: Wednesday, October 16, 2019 6:14 PM
To: Azure/azure-rest-api-specs <reply<EMAIL_ADDRESS>Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>Cc: Author <author<EMAIL_ADDRESS>Ramy Wassef <ramyw<EMAIL_ADDRESS>Subject: RE: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
Hi Kalyana,
I’ve pushed changes for this PR according to your PR review. Could you please take a look again whenever you had some time?
https://github.com/Azure/azure-rest-api-specs/pull/7509/fileshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%2Ffiles&data=02|01|kalyanaj%40microsoft.com|5d58145e34584e54c30608d7533337cf|72f988bf86f141af91ab2d7cd011db47|1|0|637069351747219385&sdata=vOrV%2F6ZiX2RqBAx83usbCxb3OFqVdLL0YnhFg6buMhY%3D&reserved=0
Thank you!
Best Regards
Hao Wang
From: J. Kalyana Sundaram <notifications<EMAIL_ADDRESS>Sent: Tuesday, October 15, 2019 6:11 PM
To: Azure/azure-rest-api-specs <azure-rest-api-specs<EMAIL_ADDRESS>Cc: Hao Wang <wanha<EMAIL_ADDRESS>Author <author<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
@kalyanaj requested changes on this pull request.
I have added my feedback, can you please take a look?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%3Femail_source%3Dnotifications%26email_token%3DANP5OWL4KQDVMBALEO3UTY3QOZS2NA5CNFSM4JBECDZKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCICF32Y%23pullrequestreview-302276075&data=02|01|kalyanaj%40microsoft.com|5d58145e34584e54c30608d7533337cf|72f988bf86f141af91ab2d7cd011db47|1|0|637069351747219385&sdata=P0cRATfFp91U3O25cqiU7%2BKPp3N7Kmy1XiI7hgS8MBs%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANP5OWPBGPYUW7DVYCR7UV3QOZS2NANCNFSM4JBECDZA&data=02|01|kalyanaj%40microsoft.com|5d58145e34584e54c30608d7533337cf|72f988bf86f141af91ab2d7cd011db47|1|0|637069351747229345&sdata=b2CXyYYD6jgZ56OUxayURP23nb9HQ5yeYaEELuXobxc%3D&reserved=0.

@wanha-ms Hello. Could you fix the errors in LintDiff and Semantic? @NullMDR Hi. Could you help us take a look at SDK's failures?

@MyronFanQiu The semantic failure should be fixed first to get sdk generation pass.

<EMAIL_ADDRESS>@NullMDRhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNullMDR&data=02|01|wanha%40microsoft.com|f2be9fa1c4c64d69583a08d755c89287|72f988bf86f141af91ab2d7cd011db47|1|0|637072192260141647&sdata=ENO2%2FvOlXL8eGupDXXzFldLOUVkN2CBOi6EoU9cp9D0%3D&reserved=0 The SDK build failure has been fixed, after updating “type”: “bool” to “type”: “Boolean”.
There seems to be a mixed usage of “type”: “bool” and “type”: “boolean” in this repo. If someone could help me understand the difference, it would be great.
From: MyronFanQiu<EMAIL_ADDRESS>Sent: Sunday, October 20, 2019 6:47 PM
To: Azure/azure-rest-api-specs<EMAIL_ADDRESS>Cc: Hao Wang<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
@wanha-mshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwanha-ms&data=02|01|wanha%40microsoft.com|f2be9fa1c4c64d69583a08d755c89287|72f988bf86f141af91ab2d7cd011db47|1|0|637072192260131648&sdata=P3z36xHImr8hMJt92dqsNZCwyHsEdkkx5keHC5rgNsY%3D&reserved=0 Hello. Could you fix the errors in LintDiff and Semantic? @NullMDRhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNullMDR&data=02|01|wanha%40microsoft.com|f2be9fa1c4c64d69583a08d755c89287|72f988bf86f141af91ab2d7cd011db47|1|0|637072192260141647&sdata=ENO2%2FvOlXL8eGupDXXzFldLOUVkN2CBOi6EoU9cp9D0%3D&reserved=0 Hi. Could you help us take a look at SDK's failures?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%3Femail_source%3Dnotifications%26email_token%3DANP5OWLUNZ65DIOALLPZV5LQPUCZPA5CNFSM4JBECDZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBY2GNY%23issuecomment-544318263&data=02|01|wanha%40microsoft.com|f2be9fa1c4c64d69583a08d755c89287|72f988bf86f141af91ab2d7cd011db47|1|0|637072192260151646&sdata=CpxsR5MsAAkB5F%2ByjipRhz04RvTjnm9RM0zcCUAEEJo%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANP5OWNC7CVO66227GSJVYDQPUCZPANCNFSM4JBECDZA&data=02|01|wanha%40microsoft.com|f2be9fa1c4c64d69583a08d755c89287|72f988bf86f141af91ab2d7cd011db47|1|0|637072192260151646&sdata=IJd4O0ZcqtKgBvZDjYuVk%2BpuhjMMefE%2B1MvPN7JcPCY%3D&reserved=0.

<EMAIL_ADDRESS>The build failure has been fixed by updating “type”: “bool” to “type”: “Boolean”.
From: Phoenix He<EMAIL_ADDRESS>Sent: Sunday, October 20, 2019 8:19 PM
To: Azure/azure-rest-api-specs<EMAIL_ADDRESS>Cc: Hao Wang<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] update-event-schema-for-azure-storage-event-grid-notification-for-cr… (#7509)
@MyronFanQiuhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMyronFanQiu&data=02|01|wanha%40microsoft.com|b0fe41cb665343d8289808d755d562ff|72f988bf86f141af91ab2d7cd011db47|1|0|637072247289064929&sdata=FMadrgrv31eJHbB%2BwwXAxs0PFumqmyR%2FFisieTrJ5JE%3D&reserved=0 The semantic failure should be fixed first to get sdk generation pass.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F7509%3Femail_source%3Dnotifications%26email_token%3DANP5OWOLPZHGXW2NAN6ZT43QPUNRNA5CNFSM4JBECDZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBY5Z7Q%23issuecomment-544333054&data=02|01|wanha%40microsoft.com|b0fe41cb665343d8289808d755d562ff|72f988bf86f141af91ab2d7cd011db47|1|0|637072247289074923&sdata=80PvOo7Pm0aHNQxD7OpcigL2TbYBxyh9KcivijZnaZQ%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANP5OWIP6MEQGXLWREF6YX3QPUNRNANCNFSM4JBECDZA&data=02|01|wanha%40microsoft.com|b0fe41cb665343d8289808d755d562ff|72f988bf86f141af91ab2d7cd011db47|1|0|637072247289074923&sdata=RgdS5NlBz44c%2Bf1S5Rdt%2FfP76o4rNtTPQfpCKahbv9s%3D&reserved=0.


[Workflows]

Ability to generate gcp workflow yaml files from code
@worfklow('name', step=1,...)
@route('xxxx')
def route_workflow_step):
...

@worfklow('name', step=1,...)
@route('/xxxx/{input}', method=get)
def route_workflow_step(inpit):
...

sample yaml
- randomgen_function:
    call: http.get
    args:
        url: https://REGION-PROJECT_ID.cloudfunctions.net/randomgen
    result: randomgen_result
- multiply_function:
    call: http.post
    args:
        url: https://REGION-PROJECT_ID.cloudfunctions.net/multiply
        body:
            input: ${randomgen_result.body.random}
    result: multiply_result
- log_function:
    call: http.get
    args:
        url: https://api.mathjs.org/v4/
        query:
            expr: ${"log(" + string(multiply_result.body.multiplied) + ")"}
    result: log_result
- floor_function:
    call: http.post
    args:
        url: CLOUD_RUN_SERVICE_URL
        auth:
            type: OIDC
        body:
            input: ${log_result.body}
    result: floor_result
- return_result:
    return: ${floor_result}

https://cloud.google.com/workflows/docs/run/tutorial-cloud-run

Today, we do create workflows with a sequence of Cloud Functions / Cloud Run containers and other GCP resources (like PubSub, Cloud Storage, etc...). It's actually very hard to monitor and visualize the full process. Google Workflows may be the missing piece to federate all the resources deployed by goblet. It would be a great advancement !
I believe the beauty of goblet is that it relies on a beautiful syntactic sugar that makes it easy to abstract the heavy lifting.
The State Of The Art of Workflow As Code is also quite close to this syntactic sugar based on decorators.
Various examples :

[Prefect's Functional API](https://docs.prefect.io/core/concepts/flows.html#functional-api and Airflow's Taskflow API represent in my opinion the best APIs for workflows.
Airflow's Custom XCom Backend is a great way to abstract the exchange of data between 2 tasks (meaning 2 Cloud Functions or 2 Cloud Run containers).

I believe this kind of syntax will allow people to create complex workflows in a simple way.  Serverless services allow to build cheap workflows compared to services and tools aiming towards the same goal (For example, Airflow & Prefect require an expensive Kubernetes cluster).
Can't wait to use Workflows with goblet !

That is exactly our use case as well! thanks for sharing the airflow and prefect examples. what i like about those tools is how easy and simply the python code is to setup those workflows.
will try to base the goblet version off of those.
will start working on some potential  architectures and share here.

It has been awhile, but finally have a working project called goblet_workflows that is now in beta. Going to be adding a bunch of features in the coming weeks, including scheduling & cli execution, but feel free to look it over. All feedback and feature requests are welcome!

goblet_workflows looks great ! I will try it as soon as possible.


How to add multiple client?

Hi, I want to ask.
How to add multiple client for this server? Or is it already accessible for multiple client?
Thanks in advance.
Asyraf.

It's already accessible for multiple clients.


Include Kubernetes 1.20 in e2e tests

What this PR does / why we need it:
This makes sure we test against 1.20 as well. This PR also removes all manifests and tests for pre-1.17, as we do not support this anymore.
Optional Release Note:
Support Kubernetes 1.20

/retest

/retest

/retest

/retest

/test pull-machine-controller-e2e-aws

/test pull-machine-controller-e2e-aws

/approve

/approve

/retest

/retest

/lgtm

/lgtm


After remove Sentinel trait, the still track player and take damage

Citizens Build: 1879
Sentinel Build: 341
Even after respawn without Sentinel, they still take damage and die.
https://media.giphy.com/media/kEboWcoAGgaV9HL7uk/giphy.gif

Fixed for build 342+


Surfacing reliability metrics in design guidance

One of the main issues I face across many apps is knowing whether my notes got posted. When I do get feedback it's not generally actionable because there's no detail that's easy to access. For example, it's hard to know which relay didn't get the post, or if I connected or still connected to a particular relay. The result of not knowing these was subscribing to failed relays or not paying for paid ones. The overall uncertainty left me asking if my notes are getting to anyone at all and questioning if Nostr works.
The solution I propose is to make reliability a first-class design consideration. I understand the desire to hide the backend as much as possible but if it's affecting UX then we should err on the side of surfacing errors while the community is small and enthusiastic so they can be fixed across the system and get it ready for the next stage of growth.

Continuing this thought, I still haven't found any site that shows any kind of reliability metrics. Maybe this is an opportunity in the shorter term for a kind of note ping tool.

Snort has a note status tool that shows which relays the note went to, or which rejected it. We thought this was a great idea, but after using it for a while people have complained (and I am also annoyed by it). I think we could design a less intrusive version and I have taken a stab at it, but there is not much development desire to implement these things.
Instead of showing all the relay statuses, I think we could show just the ones that failed, and have this feature be a tap / hover instead of showing all information at once. On desktop you'd hover over "2 relays failed" for example, and it would show you which relays failed to accept the note (with options to do something about it, delete relay, try again, etc...)
On mobile you'd have to tap that number (probably in red) to see those stats.
What do you think?

As a user, i'd love it if there were more stats for nerds in a sense that the developer has helped me make good decisions. Ping times, posting success rate, and relative lag come to mind as metrics I'd like to see more of as a user. I suppose for a design guide that it's enough that there be a section somewhere with a couple examples, not that it needs to address every use case.
It still feels early enough for Nostr and reliability a recurring enough issue that the guide deserves such a section. If you agree that reliability is important then I might try composing a PR or would be happy to collaborate as far as editing.

I think the relay settings could probably use more information. Some clients are doing better than others. If you have some ideas for that that'd be great!

Coracle has a HUD (head up display) in the right bottom, that tries to give some insight in a gentle way.
Some time ago, before the HUD, I designed this interface to improve the communication about issues when posting:
https://github.com/coracle-social/coracle/issues/411
Since Nostr communication is highly asynchronous and has a fairly high failure rate, given the distributed nature, I think this type of solution should be included in a design guide.


MWPW-161845: basic analytics on mas cards

Add basic analytics to mas cards
Resolves:  https://jira.corp.adobe.com/browse/MWPW-161845
Test URLs:

Before: https://main--milo--adobecom.hlx.live/libs/features/mas/docs/ccd.html?martech=off
After: https://MWPW-161845--milo--adobecom.hlx.live/libs/features/mas/docs/ccd.html?martech=off

@3ch023 you have removed the spacing between cards. https://mwpw-161845--mas--adobecom.hlx.live/gallery/ccd.html?milolibs=mwpw-161845--milo--adobecom
Otherwise looks good. Approving

@3ch023 you have removed the spacing between cards. https://mwpw-161845--mas--adobecom.hlx.live/gallery/ccd.html?milolibs=mwpw-161845--milo--adobecom
Otherwise looks good. Approving

just checked and it seems like it happened in a prev PR, I can reproduce on ccd branch:
https://mwpw-161845--mas--adobecom.hlx.live/gallery/ccd.html?milolibs=ccd--milo--adobecom
will fix it later, i am not 100 sure which gallery we will use once we switch to freya - might be milo gallery again..


feat: apply & jsonassertionfunc

Codecov Report

Merging #6 (8428c1f) into main (1dbecb0) will decrease coverage by 7.89%.
The diff coverage is 16.85%.

:exclamation: Current head 8428c1f differs from pull request most recent head 984e805. Consider uploading reports for the commit 984e805 to get more accurate results

@@            Coverage Diff             @@
##             main       #6      +/-   ##
==========================================
- Coverage   56.62%   48.74%   -7.89%
==========================================
  Files           6        6
  Lines         249      318      +69
==========================================
+ Hits          141      155      +14
- Misses         91      142      +51
- Partials       17       21       +4

Impacted Files
Coverage Δ

setuptest/applydestroy.go
13.84% <0.00%> (+13.84%)
:arrow_up:

check/that.go
40.98% <18.75%> (-7.91%)
:arrow_down:

setuptest/tfutils.go
84.44% <50.00%> (ø)

setuptest/dir.go
66.66% <58.33%> (ø)

... and 1 file with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Update phpdevtoool v3 to v4, phpcsfixer v2 to v3

Questions
Answers

Description?
Update to newer versions.

Type?
improvement

BC breaks?
no

Deprecations?
no

Fixed ticket?
No issue at all

How to test?
Automatic checks pass, no more php-cs-fixer v2 deprecated warning.

thanks @leemyongpakvn !


Gearpump 143

add refinement as to GEARPUMP-147.

ℵ₀ thanks for the patch!

+1, please rebase on the latest master