Merge frontend and backend into a monorepo

The backend has been added as a subtree, meaning that git retains its history.
This does however create some weird history conflicts when following files through renames. If a file had the same name in frontend and backend (like README.md), git merges their history when showing the log. This does not impact the files or the repo log, only the log retrieved for that one file.

@FredrikAugust @KaizerTilt @NicolajNiels1 @joachifm
I've set up docker and circle-ci. The website works, but the tests fail. Locally there are some recent changes in the backend that aren't reflected in the frontend. @FredrikAugust will fix that soon.
However, the frontend tests don't run at all in circle-ci because react-scripts isn't installed. Does anyone have any idea why this works locally but not on circle-ci?

@joachifm You seem to be experienced with docker. Do you see anything that can be improved in the docker and docker-compose files?

@kalkins one other thing occurred to me: though it breaks running migrations inside the container, running the apps readonly in production would be prudent. I believe this can be achieved fairly cleanly by supplying a prod override compose file, that sets read_only: true on the services & mounts /code read-only.

react-scripts has to be installed globally (or be in PATH) for it to
work. It should work out of the box after running yarn, but you could run
the local binary instead - node_modules/.bin/react-scripts. That could
work. It did work just fine in CircleCI before though, so I think something
might be wrong with the setup of that.
El sáb., 10 ago. 2019 16:04, Joachim F<EMAIL_ADDRESS>escribió:

@kalkins https://github.com/kalkins one other thing occurred to me:
though it breaks running migrations inside the container, running the apps
readonly in production would be prudent. I believe this can be achieved
fairly cleanly by supplying a prod override compose file, that sets read_only:
true on the services & mounts /code read-only.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2GYFVUMTT7B7DIGC2Y3QD3DHLA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AOEHY#issuecomment-520151583,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2V2G4PMCPIWYZ2G3QX42TQD3DHLANCNFSM4IKNEQPQ
.

There might be an image that ships with yarn, which would be better as you
need it. After that, just run yarn before doing anything with the
frontend - this installs the deps.
El sáb., 10 ago. 2019 17:55, Sindre Stephansen<EMAIL_ADDRESS>escribió:

@kalkins commented on this pull request.
In frontend/Dockerfile
https://github.com/Kodeworks/liquidator-frontend/pull/128#discussion_r312707359
:

@@ -0,0 +1,18 @@
+FROM node:latest

+#RUN useradd frontend -u 1000 -U -s /bin/false
Opps, didn't read through your comment properly. Yes, I can try the node
user
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2G4X273ZUAZYRUR6XDLQD3QGJA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCBGDOZQ#discussion_r312707359,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2V2G25KAGZKM3EXUNSRNDQD3QGJANCNFSM4IKNEQPQ
.

There was a seperate yarn image, but it's deprecated as yarn is provided with the standard node image

Alright, great.
El sáb., 10 ago. 2019 17:59, Sindre Stephansen<EMAIL_ADDRESS>escribió:

There was a seperate yarn image, but it's deprecated as yarn is provided
with the standard node image
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2G6LX2MVUQ2DEEAVE63QD3QVVA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AQEXY#issuecomment-520159839,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2V2GZM2NBT2N6PFAD74TLQD3QVVANCNFSM4IKNEQPQ
.

Does yarn only need package.json and yarn.lock when getting dependencies? It would improve caching if we could copy over those files, install dependencies, and then copy over the rest of the project

Correct. It only needs those two.
El sáb., 10 ago. 2019 18:01, Sindre Stephansen<EMAIL_ADDRESS>escribió:

Does yarn only need package.json and yarn.lock when getting dependencies?
It would improve caching if we could copy over those files, install
dependencies, and then copy over the rest of the project
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2G74X7RINUUMFD7ZZE3QD3Q4PA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AQFZI#issuecomment-520159973,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2V2GZIN7WSKZNZ37FYSELQD3Q4PANCNFSM4IKNEQPQ
.

Does this use yarn start in prod? Because if so, it should be changed to run yarn buld, and then serve the files staticly

I used yarn start because it was easier while setting up docker, and making sure they worked together. We have to do something about that before moving to prod. This is also related to something Joachim said earlier:

@kalkins one other thing occurred to me: though it breaks running migrations inside the container, running the apps readonly in production would be prudent. I believe this can be achieved fairly cleanly by supplying a prod override compose file, that sets read_only: true on the services & mounts /code read-only.

I was thinking of doing something similar to the run commands, so we get hot reload while developing, and production builds in production. @joachifm Could we do this with environment variables instead of separate compose files? So we have read_only: ${PROD} or something like that? For the run commands we could either have a one-line bash command or a separate script that starts the dev server, or does a prod build

Sounds good to me, as long as we don't run yarn start in prod we should be
all good!
El sáb., 10 ago. 2019 18:23, Sindre Stephansen<EMAIL_ADDRESS>escribió:

Does this use yarn start in prod? Because if so, it should be changed to
run yarn buld, and then serve the files staticly
I used yarn start because it was easier while setting up docker, and
making sure they worked together. We have to do something about that before
moving to prod. This is also related to something Joachim said earlier:
@kalkins https://github.com/kalkins one other thing occurred to me:
though it breaks running migrations inside the container, running the apps
readonly in production would be prudent. I believe this can be achieved
fairly cleanly by supplying a prod override compose file, that sets read_only:
true on the services & mounts /code read-only.
I was thinking of doing something similar to the run commands, so we get
hot reload while developing, and production builds in production.
@joachifm https://github.com/joachifm Could we do this with environment
variables instead of separate compose files? So we have read_only: ${PROD}
or something like that? For the run commands we could either have a
one-line bash command or a separate script that starts the dev server, or
does a prod build
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2G7L3NRKQLXM4VU7W4LQD3TR5A5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AQUMQ#issuecomment-520161842,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2V2G5BZHZIHHGG6M4HUTLQD3TR5ANCNFSM4IKNEQPQ
.

react-scripts has to be installed globally (or be in PATH) for it to work. It should work out of the box after running yarn, but you could run the local binary instead - node_modules/.bin/react-scripts. That could work. It did work just fine in CircleCI before though, so I think something might be wrong with the setup of that.

The weird thing is, the error in circle-ci is /bin/sh: react-scripts: not found. When I try to run react-scripts as part of the Dockerfile locally, I get the same error. However, if I try to do docker-compose run frontend react-scripts, I get this error:
internal/modules/cjs/loader.js:716
    throw err;
    ^

Error: Cannot find module '/frontend/code/react-scripts'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:713:15)
    at Function.Module._load (internal/modules/cjs/loader.js:618:27)
    at Function.Module.runMain (internal/modules/cjs/loader.js:931:10)
    at internal/main/run_main_module.js:17:11 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

When I run docker-compose run frontend yarn test it says it runs react-scripts test --testPathIgnorePatterns "mitochondria", which works fine locally, but not in circle-ci.

There probably is a problem with path resolving or something along those
lines.
I do not know how this happens, but the way it should ideally be run is
like this:

CD into dir
Yarn
Yarn start

This way the working directory is the root of the frontend.
El sáb., 10 ago. 2019 18:48, Sindre Stephansen<EMAIL_ADDRESS>escribió:

react-scripts has to be installed globally (or be in PATH) for it to
work. It should work out of the box after running yarn, but you could run
the local binary instead - node_modules/.bin/react-scripts. That could
work. It did work just fine in CircleCI before though, so I think something
might be wrong with the setup of that.
The weird thing is, the error in circle-ci is /bin/sh: react-scripts: not
found. When I try to run react-scripts as part of the Dockerfile locally,
I get the same error. However, if I try to do docker-compose run frontend
react-scripts, I get this error:
internal/modules/cjs/loader.js:716
throw err;
^
Error: Cannot find module '/frontend/code/react-scripts'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:713:15)
at Function.Module._load (internal/modules/cjs/loader.js:618:27)
at Function.Module.runMain (internal/modules/cjs/loader.js:931:10)
at internal/main/run_main_module.js:17:11 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}
When I run docker-compose run frontend yarn test it says it runs react-scripts
test --testPathIgnorePatterns "mitochondria", which works fine locally,
but not in circle-ci.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2G2LA53HD7WOX6YNZQLQD3WNTA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ARDDA#issuecomment-520163724,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2V2G6D7SKLETTXHGDPVOTQD3WNTANCNFSM4IKNEQPQ
.

Thats what we do. Is there a way to install/set up the path to react-scripts manually so we are sure it will be available?
On Sat, Aug 10, 2019, at 18:54, Fredrik August Madsen-Malmo wrote:

There probably is a problem with path resolving or something along those
lines.
I do not know how this happens, but the way it should ideally be run is
like this:

CD into dir
Yarn
Yarn start

This way the working directory is the root of the frontend.
El sáb., 10 ago. 2019 18:48, Sindre Stephansen<EMAIL_ADDRESS>escribió:

react-scripts has to be installed globally (or be in PATH) for it to
work. It should work out of the box after running yarn, but you could run
the local binary instead - node_modules/.bin/react-scripts. That could
work. It did work just fine in CircleCI before though, so I think something
might be wrong with the setup of that.
The weird thing is, the error in circle-ci is /bin/sh: react-scripts: not
found. When I try to run react-scripts as part of the Dockerfile locally,
I get the same error. However, if I try to do docker-compose run frontend
react-scripts, I get this error:
internal/modules/cjs/loader.js:716
throw err;
^
Error: Cannot find module '/frontend/code/react-scripts'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:713:15)
at Function.Module._load (internal/modules/cjs/loader.js:618:27)
at Function.Module.runMain (internal/modules/cjs/loader.js:931:10)
at internal/main/run_main_module.js:17:11 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}
When I run docker-compose run frontend yarn test it says it runs react-scripts
test --testPathIgnorePatterns "mitochondria", which works fine locally,
but not in circle-ci.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2G2LA53HD7WOX6YNZQLQD3WNTA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ARDDA#issuecomment-520163724,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2V2G6D7SKLETTXHGDPVOTQD3WNTANCNFSM4IKNEQPQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB4GLNEJ4UK7J7PPJ3P3K6TQD3XEDA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ARGDI#issuecomment-520164109, or mute the thread https://github.com/notifications/unsubscribe-auth/AB4GLNB4N7BTQ3MLF7TSOYDQD3XEDANCNFSM4IKNEQPQ.

I replied to that earlier in the thread. On mobile right now so finding
that is a bit tedious.
El sáb., 10 ago. 2019 18:57, Sindre Stephansen<EMAIL_ADDRESS>escribió:

Thats what we do. Is there a way to install/set up the path to
react-scripts manually so we are sure it will be available?
On Sat, Aug 10, 2019, at 18:54, Fredrik August Madsen-Malmo wrote:

There probably is a problem with path resolving or something along those
lines.
I do not know how this happens, but the way it should ideally be run is
like this:

CD into dir
Yarn
Yarn start

This way the working directory is the root of the frontend.
El sáb., 10 ago. 2019 18:48, Sindre Stephansen<EMAIL_ADDRESS>escribió:

react-scripts has to be installed globally (or be in PATH) for it to
work. It should work out of the box after running yarn, but you could
run
the local binary instead - node_modules/.bin/react-scripts. That could
work. It did work just fine in CircleCI before though, so I think
something
might be wrong with the setup of that.
The weird thing is, the error in circle-ci is /bin/sh: react-scripts:
not
found. When I try to run react-scripts as part of the Dockerfile
locally,
I get the same error. However, if I try to do docker-compose run
frontend
react-scripts, I get this error:
internal/modules/cjs/loader.js:716
throw err;
^
Error: Cannot find module '/frontend/code/react-scripts'
at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:713:15)
at Function.Module._load (internal/modules/cjs/loader.js:618:27)
at Function.Module.runMain (internal/modules/cjs/loader.js:931:10)
at internal/main/run_main_module.js:17:11 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}
When I run docker-compose run frontend yarn test it says it runs
react-scripts
test --testPathIgnorePatterns "mitochondria", which works fine locally,
but not in circle-ci.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2G2LA53HD7WOX6YNZQLQD3WNTA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ARDDA#issuecomment-520163724
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AB2V2G6D7SKLETTXHGDPVOTQD3WNTANCNFSM4IKNEQPQ

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB4GLNEJ4UK7J7PPJ3P3K6TQD3XEDA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ARGDI#issuecomment-520164109>,
or mute the thread <
https://github.com/notifications/unsubscribe-auth/AB4GLNB4N7BTQ3MLF7TSOYDQD3XEDANCNFSM4IKNEQPQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Kodeworks/liquidator-frontend/pull/128?email_source=notifications&email_token=AB2V2G76J4ZDKSMZ4JJLSTLQD3XPJA5CNFSM4IKNEQP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ARH4A#issuecomment-520164336,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2V2G25U3XMCIIJ4YHDTGLQD3XPJANCNFSM4IKNEQPQ
.

I've found and fixed the issue with react-scripts now. The problem was that the node modules were installed in the workdir, which was then overwritten by the volume mount. The reason it worked for me was that i had the modules installed from before. I fixed it by moving the node modules up to the parent folder.

The CI works now, there are only the three tests i mentioned previously that still fails.
I have set up the api tests so they run in a separate project, meaning that the containers and volumes don't interfere with the ones we use normally. The database is reset before each test run, so if a test fails the database can be inspected, but it won't affect future tests.

Seems like tslint isn't available. @kalkins could you take a look at this?

@FredrikAugust I've fixed tslint, so all the checks pass. I'm not sure if pep8speaks works with this setup (and it isn't activated for this repo yet), but we can fix that later

@joachifm Do you have any thoughts about this: https://github.com/Kodeworks/liquidator-frontend/pull/128#issuecomment-520161842

@kalkins

Could we do this with environment variables instead of separate compose files? So we have read_only: ${PROD} or something like that? For the run commands we could either have a one-line bash command or a separate script that starts the dev server, or does a prod build

I'm confident this can be accomplished with environment variables as well.  But to elaborate a little bit on the case for a declarative approach with compose files:
The compose file approach only requires listing the keys that should be overridden.  Suppose you have docker-compose.{prod,dev}.yml, then a wrapper could do docker-compose -f docker-compose.yml -f docker-compose.${ENV}.yml up -d. The final docker-compose.yml should be the result of merging all the listed files.
I have a patch against the old backend repo that adds a docker-compose.prod.yml that contains only
services:
  web:
    read_only: true
    volumes:
      - .:/code:ro

I think this could be simplified further by omitting the bind-mount of pwd into the container from the base composition and only doing that in the dev override. To my eyes this is fairly low-overhead.
I believe this would work for run instructions as well (just declare different commands in dev and prod, or change relevant envvars to use different ports or whatever).
If different build instructions are desired, it seems most efficient to me to use a layerered approach, where dev is derived from prod (or both derived from a common base, whichever is most convenient).

@joachifm I realized how it could be done shortly after pinging you, and I'm working on it now.
Using environment variables would be complicated and hacky, and the fact that we can override the relevant parts of the compose file makes it a better option. Currently I'm trying to use docker-compose.yml as the base and docker-compose.override.yml as test/dev, as that is used by default. Then we have docker-compose.prod.yml which is used is production.
I agree with removing the bind mounts, and that is the approach I'm taking now. The files are copied during the docker build anyway.
Should we remove the final commands from the dockerfiles and have them in the compose file instead? That might make it more clear. Currently I'm just having the dev commands in the dockerfile and overriding them in the prod compose file.

@FredrikAugust The tests run fine, but the frontend fails to compile:
/frontend/code/src/store/reducers/company.ts
TypeScript error in /frontend/code/src/store/reducers/company.ts(75,30):
Argument of type 'ICompanyUser' is not assignable to parameter of type 'IAddCompanyUser'.
  Property 'email' is missing in type 'ICompanyUser' but required in type 'IAddCompanyUser'.  TS2345

    73 |   dispatch: React.Dispatch<ICreatedAction>
    74 | ) => {
  > 75 |   await API.addUserToCompany(user);
       |                              ^
    76 |   dispatch(addUserToCompany(user));
    77 | };
    78 |

@kalkins

Currently I'm just having the dev commands in the dockerfile and overriding them in the prod compose file.

If run instructions are kept in the dockerfile, I agree they should be for dev (or at least not expose the app to the open internet by default).
I think keeping everything in the compose files makes sense, even if for no other reason than consistency.

And it now build successfully @kalkins.

@kalkins can you merge this?

@kalkins You just broke the tests with your last two commits. I'm getting a 502 Bad Gateway on all requests to the backend.

Eh, there's some weird django error. I reverted it so we still have the commit in the history


ci: simplify setup

Can save a minute per job on the build (done) and avoids checking typescript types over and over (todo), saving another minute per job. Instead, a single job will check all types, and won't do it for every node version or binary type.

Closing in favor of https://github.com/prisma/prisma/pull/20616


pc无法进行访问

What happened?
无法使用浏览器进行访问11001端口，但是11002可以进行访问

手机上就可以访问
下面的docker的状态

使用的版本的最新版的git进行下载的

What did you expect to happen?
1
How can we reproduce it (as minimally and precisely as possible)?
1
Anything else we need to know?
1
version

```console
$ {name} version
# paste output here
```

Cloud provider

OS version

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here
# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

Install tools

Delete the old images, then run docker compose up -d.


Delete empty uns dict keys

Many datasets are failing a schema validation requirement that uns not contain values that are empty (excludes bool and NoneType types).

A related issue we found is that this doesn't actually work if the value is numpy.bool_. Going to be putting up a fix to both the original validation code as well as the migrate script

This should now be closed with: https://github.com/chanzuckerberg/single-cell-curation/pull/803


Complementing README.md with jekyll commands

Complementing README.md with jekyll commands, to specify how to run the project, or how to install ruby and jekyll.

Closed by https://github.com/scanapi/website/pull/45

Closed by https://github.com/scanapi/website/pull/45


Improve documentaion

The example page and documentation need improvement. I have decided I'm not using sass-doc for this so I am currently exploring other options.

Note: I am exploring http://readme.io as an option that would cover both needs as far as documentation and a homepage/marketing page.

Progress can be previewed over at https://cask.readme.io/v1.0

Primary buildout on https://cask.readme.io has been completed.


Do not invalidate pages in visits that don't render

Fixes https://github.com/hotwired/turbo/issues/1047
Supersedes https://github.com/hotwired/turbo/pull/1143
Rendering a frame with a data-turbo-action was rendering the response twice.
First, the FrameController in charge of the frame renders the response using a FrameRenderer, while processing callback the loadResponse callback.
https://github.com/hotwired/turbo/blob/b7187f13b216cee8c855ef1fb6ac790b40dde361/src/core/frames/frame_controller.js#L314
But when we update a frame with a data-turbo-action, we also issue a visit to update the browser URL & history:
https://github.com/hotwired/turbo/blob/b7187f13b216cee8c855ef1fb6ac790b40dde361/src/core/frames/frame_controller.js#L373
This session visit was also triggering a loadResponse callback, which in turn was instantiating a PageSnapshot and rendering it.
This caused problems when the response for the frame didn't include all the tracked assets in the page. The page snapshot considered the assets stale and triggered a reload of the page with reason tracked_element_mismatch.
This commit fixes the issue by not rendering the page snapshot when navigating from a frame.
The commit includes a new test that reproduces the issue returning a turbo frame in an HTML document with an empty <head>. Before this fix, the response would trigger a full page reload.
This is the call stack before the fix. Notice the two calls to loadResponse.

Nice! A couple of things:
Is fromFrame set for the same purpose as willRender. As far as I can tell, willRender is only set to false for this frame visit case, in which case, could we just re-use that?
What is the frame visit actually doing? It doesn’t render and it’s instantiated with updateHistory: false. It looks like FrameController#changeHistory is already called and it doesn’t render, so is it needed at all?

What is the frame visit actually doing? It doesn’t render and it’s instantiated with updateHistory: false. It looks like FrameController#changeHistory is already called and it doesn’t render, so is it needed at all?

😵💫 From the looks of the failing tests (any my own brief manual tests), it looks like the visit is doing a fair bit (on the caching front?)

As far as I can tell, willRender is only set to false for this frame visit case, in which case, could we just re-use that?

That's a good idea. I've updated the PR so now we use willRender to ensure we are not invalidating a page in a visit that wouldn't render anyway.

What is the frame visit actually doing? It doesn’t render and it’s instantiated with updateHistory: false. It looks like FrameController#changeHistory is already called and it doesn’t render, so is it needed at all?

This was introduced in https://github.com/hotwired/turbo/pull/398/ to add navigation-like behavior to to frame navigations with data-turbo-action. It's a bit difficult to follow everything that's happening, and it'd be nice if we had some abstractions to do this without having to issue a new visit but that's a big change that would require changing many internal parts of Turbo.
For now this small patch fixes https://github.com/hotwired/turbo/issues/1047, which is the main blocker for a Turbo 8 final release. If we're happy with this I think are ready for the final release.

If we're happy with this I think are ready for the final release.

@afcapel Sorry to bother with this but, have you considered any of these concerns before releasing the stable version? #1080 (Turbo crashes completely, I opened #1098 to address it). Other concerns with full page reloading when assets are diferent #1105 and #1116. Thanks!

If we're happy with this I think are ready for the final release.

@afcapel Sorry to bother with this but, have you considered any of these concerns before releasing the stable version? #1080 (Turbo crashes completely, I opened #1098 to address it)

I second that closing #1080 (causing blank pages with replace navigations!), would need to be part of a stable release. The potential fix in #1098 makes a lot of sense. We're seeing flashes of unwanted content (stale snapshots) while performing refreshes with morphing. It kinda defeats the purpose of the new shiny morph refreshes.
Let me know if we can do anything to help out here?

Ok, I'll do a final round before publishing a RC 👍
Aiming to fix:

https://github.com/hotwired/turbo/issues/1047
https://github.com/hotwired/turbo/issues/1080
https://github.com/hotwired/turbo/issues/1105
https://github.com/hotwired/turbo/issues/1116

All of them have PRs already open to address them, so it's a matter of validating and merging.
Anything we should consider a blocker?

@seanpdoyle has made a big effort with contributions and there are still many unmerged, several bug fixes and some very old ones. If you have time, it would be great if you could review as much as you can, obviously within your availability.

Sure, I'd also like to clean up the remaining PRs, but unfortunately right now I'm focused on another project and have limited availability. We could always do more, but for context, we've already merged 72 PRs since v7.3.0.

Out of the pull requests that I've opened at the moment, I consider two are worth merging into 8:

https://github.com/hotwired/turbo/pull/1135 (closes #468 and #489)
https://github.com/hotwired/turbo/pull/1141 (but depends on idiomorph@main)

The others either require additional troubleshooting, or are refactors and abstractions.

Cool, thanks @seanpdoyle I'll be sure to review those two as well before the RC.
As for other refactorings, they are of course welcome but they'll probably have to wait until after the v8 release.


"Manage All Clusters" at the global level , "Manage projects" at the cluster level and "Cluster owners" do not have the ability to  add/delete/modify member list for projects they have access to.

Rancher version - 2.0 built on Jan 23
Steps to reproduce the problem:
As admin user:

Create a cluster1 - C1 with project P1.
Create a user - user1 as standard user.

Scenario1:
Add "user1" as "cluster owner" role to C1.
user1 will have the ability to delete project P1. But not have the ability to  add/delete/modify member list for project P1.
Scenario2:
Add "user1" with "Manage Projects" role to C1.
user1 will have the ability to delete project P1. But not have the ability to  add/delete/modify member list for project P1.
Scenario3:
Create user user2 with custom role - "Manage All Clusters".
User2 will have the ability to delete project P1. But not have the ability to  add/delete/modify member list for project P1.
In all above scenarios , It is more intuitive to assume that these users are given the ability to  add/delete/modify member list for project when they have ability to delete the projects.

With the changes in how we handle adding users to clusters/projects and using owner or member, scenario 1 and 2 appeared to be fixed. Let's re-test.
I don't think Scenario 3 is valid anymore as the custom roles are clearly defined and there is a space for "managing" the users.

Tested with master from Feb 28. Scenario 1 is still not functional.
As a cluster owner, adding project members, listing project members and deleting is not functional.

Scenario 2 seems like it is a custom  with "Manage Projects" role. This cannot be tested at the moment as there is issue https://github.com/rancher/rancher/issues/11696

Spoke with @cjellick and this is the current design decision.
Cluster ownership, ability to manage clusters/projects does not automatically provide permissions to manage project membership without explicitly being added to the project with these permissions.

We will be updating so that "Custer Owners" will automatically be given permissions to manage project members.
Cluster Members would need this permissions explicitly added as cluster members only have these perms:
-> Create Projects
-> View Cluster Members
-> View Nodes
-> Use Volumes

Tested with latest 2.0 build from master.
cluster owners now has the ability to add/remove member for the cluster.
"Manage Projects" and "Manage All Clusters" roles  are not present any more.


Update statistics to 2.3.0

Please update my adapter ioBroker.statistics to version 2.3.0.
This pull request was created by https://www.iobroker.dev c0726ff.

Update confirmed
https://github.com/iobroker-community-adapters/ioBroker.statistics/issues/152#issuecomment-1493261031


Use DocStringExtensions

Improve documentation quality and robustness to future code changes by using DocStringExtensions.jl. Particularly:
FIELDS, SIGNATURES, and EXPORTS.

This PR can also update the doc format to satisfy the CliMA Documentation Policy

@valeriabarra , this should help with the docstring task in #205


feat: improvise dirty build time

Fixes #1402
Changes: Improvise build time
Screenshots for the change:

Enabling the Gradle daemon is not viable for everyone. Especially if you're running on a machine with 8 gigs of RAM or less. This is not the way to improve the build speed. I have two machines, one mac and one linux, both having 8 GB of RAM. The Gradle daemon makes them nearly unusable when enabled, even on multi module projects which have parallelized builds. I strongly recommend against this decision.
A better method would be to modularize the project.

I am currently using a mac with 8 gigs of ram and it works just fine and it's not just that there is also configure on demand and increasing the heap size @iamareebjamal what are your thoughts on this

What about the people with 4 Gigs of RAM? Or people who do other things on their system while also running Android Studio? IMO Gradle daemon is a strictly local setting. Everyone should configure it for their own machines, instead of forcing everyone to use the same settings.

Yes, this does not improve the CI build time and Android Studio automatically utilizes daemon on supported machines


contrib-sip-proxy: Fix Issues of request_active_ counter and mismatched tra context

Fix issue 22306
Fix issue of mismatched tra context

Signed-off-by: Felix Du<EMAIL_ADDRESS>
Commit Message:
Additional Description:
Risk Level: Low
Testing: UT
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue] https://github.com/envoyproxy/envoy/issues/22306
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@dorisd0102 Please help to review this,
Thanks.

/LGTM

@phlax  Please help to merge this,
Thanks in advance.

LGTM

/assign-from @envoyproxy/envoy-maintainers

/assign-from @envoyproxy/envoy-maintainers


fix: add aria label to select element for content types

Added an aria-label to the content type selector to improve accessibility
Motivation and Context
Imporve swagger-ui accessibility
How Has This Been Tested?
Tested with aXe and a screen reader

make a pr to va swagger repo


Babel 6 explicit function parameter type support?

Unfortunately, I am stuck on Babel 6 until babel-plugin-flow-runtime supports Babel 7.
This means I am unable to use Flow >= 0.85.0, which requires explicit function type parameter annotations in some cases, because Babel 6 doesn't support them:
$ babel src/universal/redux/sidebar.js
SyntaxError: src/universal/redux/sidebar.js: Unexpected token (53:66)
  51 | }
  52 |
> 53 | export const sidebarReducer = combineReducers<SidebarState, Action>({
     |                                                                   ^
  54 |   open: createReducer(null, {
  55 |     [SET_SIDEBAR_OPEN]: (state: State, action: SetSidebarOpenAction) => action.payload,
  56 |   }),

I am suffering :cry:
Is there any plugin for Babel 6 that makes it handle this syntax?

Unfortunately I think you'll have to wait for it to support Babel 7.


Github - Node.js 16 actions are deprecated.

[Auto Request Review]
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20<EMAIL_ADDRESS>For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Thanks for pointing that out 👍 Resolved in #117


Fix top nav highlight bug when send or receive button is selected

Resolves #555
The first issue with the address card has been resolved.
This PR resolves bug with Highlighting selected top Nav page button.

Old UI

*New UI

The highlight ripple animation doesn't show when the buttons are pressed, unlike other clickables.

After troubleshooting this request, it was observed that the reason for this was that the card widget used to highlight the currently selected tab was overlaying the button effect.
We will create a task for the button effect and fix this from another PR after #563 is merged.


fix: 🐛 add resizeOptions to getContentArea

Description
#2408 添加 direction 后，之前的行为发生了变化，此 PR 部分修复了该问题。

Motivation and Context

resizeOptions 中提供了 useCellGeometry 设置，决定是否使用 model 计算尺寸。 #2408 中未使用此参数的值
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Enhancement (changes that improvement of current feature or performance)
[ ] Refactoring (changes that neither fixes a bug nor adds a feature)
[ ] Test Case (changes that add missing tests or correct existing tests)
[ ] Code style optimization (changes that do not affect the meaning of the code)
[ ] Docs (changes that only update documentation)
[ ] Chore (changes that don't modify src or test files)

Self Check before Merge

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

当然，#2408 添加的 calcContextArea 方法中的 getCellBBox 也并未考虑 useCellGeometry，最后返回也是直接使用 this.model.getCellsBBox(calculativeCells)，本 PR 未对这些行为进行修复，仅保证未使用新添加的 directions 时行为与之前版本一致


Slow down caused by integration

I haven't had time to thoroughly test this yet however I think the integral is being evaluated for every data point in the likelihood, resulting in a significant reduction in performance.

On closer evaluation I think this may actually be caused by the change in default parameters for the minimiser #49.

The default parameters for the ScipyLBFGSBOptimizer are definitely not optimal at the moment (Pun intended).
My logic when setting them was basically "It works for a normal distributions, so it's gotta be good enough for everything else".
Shall we close this issue and open a new one for the optimizer parameters?

My logic when setting them was basically "It works for a normal distributions, so it's gotta be good enough for everything else".

What could possibly go wrong? :laughing:
Making a new issue for optimising the parameters of ScipyLBFGSBOptimizer sounds good :+1:


I'm new  of this chainer,Is problem  my vision of python or any other problem ?I doon't know what should i  do ?could you help me  ?

Load segmentation weights
Push Model to GPU
Main Begins
Exception in thread prefetch_loop:
Traceback (most recent call last):
File "/home/lvv/anaconda2/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/home/lvv/anaconda2/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
File "/home/lvv/anaconda2/lib/python2.7/site-packages/chainer/iterators/multiprocess_iterator.py", line 336, in _run
alive = self._task()
File "/home/lvv/anaconda2/lib/python2.7/site-packages/chainer/iterators/multiprocess_iterator.py", line 355, in _task
data_all = future.get(_response_time)
File "/home/lvv/anaconda2/lib/python2.7/multiprocessing/pool.py", line 572, in get
raise self._value
AttributeError: 'NoneType' object has no attribute 'shape'

Hello, Do you know how to compute the rank1 and mAP? could you give me the code which compute the rank1 and mAP, My mail is<EMAIL_ADDRESS>Thank you very much!

your dataset images are not being loaded. Check the dataset path and debug image_path in get_example in datachef.py


Display bug?

With Julia 1.6-rc1:
julia> Float8(3.1)
Float8(0x49)

That's the same on all Julia versions. I haven't implemented show(x::Float8) yet. I guess one could do
function show(io::IO, x::Float8)
    if isinf(x)
        print(io, x < 0 ? "-Inf8" : "Inf8")
    elseif isnan(x)
        print(io, "NaN8")
    else
	io2 = IOBuffer()
        print(io2,Float32(x))
        f = String(take!(io2))
        print(io,"Float8("*f*")")
    end
end

which would give
julia> Float8(3.1)
Float8(3.125)

where you have function show write function Base.show

This had been resolved in main but not registered yet. Now from 0.1.1 onwards this is resolved


add async HTTP support with 3-arity handler versions

Thanks for pull request!
It looks very good, but this project does not use vertical alignment style in let, map literals, etc.
example for
(let [res (handler req)
      header-value (or (when policy-generator
                         (some-> (policy-generator req)
                                 (compose*)))
                       default-policy)]
  (assoc-in res [:headers header-name] header-value))

{:default-src [:self]
 :block-all-mixed-content true
 :script-src [:self]}

Could you adjust this style?

Yeah, of course! Will get back to this later today 👍

Ok @egs33 , just force pushed the commit with styles aligned.

Thank you!


[branch-2.8] [Broker] Fix and improve topic ownership assignment (#13069)

Motivation
Backports #13069 to branch-2.8

I triggered a separate build for branch-2.8 in #13122 to compare differences.
@315157973 Are you the release manager for 2.8.2 ? Have you already checked that all tests pass on branch-2.8?


⚠ Samsung has degraded performance

In aa2c153, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2743 ms

Resolved: Samsung performance has improved in 1dc6874.


manager: Fix connection limits tracking of rejected connections

This PR ensures that connection IDs are properly tracked to enforce connection limits.
After ~1/2 days the substrate litep2p running node is starting to reject multiple pending socket connections.
This is related to the fact that accepting of established connection is a two-part process:

step 1. Can we accept the connection based on number of connections?
step 2. The transport manager transitions the peer state
step 3. If the transition succeeds, the connection is tracked (inserted in a hashmap).

If step 2 fails, we were previously leaking the connection ID. The connection ID is also counting towards the maximum number of connections the node can sustain.
This PR effectively modifies the connection limits API, on_connection_established is split into two methods:

can_accept_connection()
accept_established_connection()

This fixes a subtle memory leak bounded at 10000 Connection IDs.
However, even more important, this fixes connection stability for long-running nodes.
Discovered during the investigation of:

https://github.com/paritytech/litep2p/issues/282

cc @paritytech/networking

After further testing, it looks like we have duplicate connection IDs or missing out on Established events.
I would wait a bit until I completely sort this out

Coming back with more data, the PR is ready for review.
The discrepancy I've seen was related to the fact that we don't enable outbound connection limits from substrate. Therefore, the connection limits will count the inbound peers. This was leading to some confusion from my part, as I was expected the limits (66) to reflect the total connections (667):
status limits_in=66 limits_out=0 num_connected=667 num_inbound=66 num_outbound=601


scipy.interpolate.interp2d has unexpected behavior with Nan values

I'm seeing what I would consider to be unexpected behavior from the scipy interpolate.interp2d function when there are NaN values in the input array.  The code snippet below should demonstrate the problem I'm seeing, namely that the interpolated grid has NaN values in all the rows above my little corner of NaN values in the input grid.  Questions:

Is this the intended behavior?  If so, why?
How can I achieve the results that would be more consistent between rows and columns?

import numpy as np
from scipy import interpolate
nrows = 4
ncols = 4
z = np.arange(0,nrows*ncols,dtype=np.float).reshape((nrows,ncols))
z[-2][0] = np.nan
z[-1][0] = np.nan
z[-2][1] = np.nan
z[-1][1] = np.nan
print z
print
x = np.arange(0,ncols)
y = np.arange(0,nrows)
xi = np.arange(0.5,ncols-1,1.0)
yi = np.arange(0.5,nrows-1,1.0)
f = interpolate.interp2d(x,y,z,kind='linear')
zi = f(xi,yi) #interpolate at the points in between values
print zi
This returns:
[[  0.   1.   2.   3.]
[  4.   5.   6.   7.]
[ nan  nan  10.  11.]
[ nan  nan  14.  15.]]
[[  nan   nan   4.5]
[  nan   nan   8.5]
[  nan   nan  12.5]]
Why don't I get:
[[  2.5   3.5   4.5]
[  nan   nan   8.5]
[  nan   nan  12.5]]

Ok, this gets even weirder.  Depending on which corner you fill in with NaN values, you get very different results.  Here are the three other options:
########### Option 2: NaN's in upper right corner############
nrows = 4
ncols = 4
z = np.arange(0,nrows*ncols,dtype=np.float).reshape((nrows,ncols))
z[0][-2] = np.nan
z[0][-1] = np.nan
z[1][-2] = np.nan
z[1][-1] = np.nan
print z
print
x = np.arange(0,ncols)
y = np.arange(0,nrows)
xi = np.arange(0.5,ncols-1,1.0)
yi = np.arange(0.5,nrows-1,1.0)
f = interpolate.interp2d(x,y,z,kind='linear')
zi = f(xi,yi) #interpolate at the points in between values
print zi
####################################################
########### Option 3: NaN's in upper left corner############
nrows = 4
ncols = 4
z = np.arange(0,nrows*ncols,dtype=np.float).reshape((nrows,ncols))
z[0][0] = np.nan
z[0][1] = np.nan
z[1][0] = np.nan
z[1][1] = np.nan
print z
print
x = np.arange(0,ncols)
y = np.arange(0,nrows)
xi = np.arange(0.5,ncols-1,1.0)
yi = np.arange(0.5,nrows-1,1.0)
f = interpolate.interp2d(x,y,z,kind='linear')
zi = f(xi,yi) #interpolate at the points in between values
print zi
####################################################
########### Option 3: NaN's in lower right corner############
nrows = 4
ncols = 4
z = np.arange(0,nrows*ncols,dtype=np.float).reshape((nrows,ncols))
z[-2][-2] = np.nan
z[-2][-1] = np.nan
z[-1][-2] = np.nan
z[-1][-1] = np.nan
print z
print
x = np.arange(0,ncols)
y = np.arange(0,nrows)
xi = np.arange(0.5,ncols-1,1.0)
yi = np.arange(0.5,nrows-1,1.0)
f = interpolate.interp2d(x,y,z,kind='linear')
zi = f(xi,yi) #interpolate at the points in between values
print zi
####################################################

There's no NaN handling in the code. The behavior is undefined if they
are present.

Ok, so in the short term I think I would at least recommend noting the NaN behavior in the documentation.
In the medium to long term, I suggest that supporting NaN values in interpolation would be a good thing.
There are at least 2 packages that handle NaN for the same kind of function:
http://www.mathworks.com/help/matlab/ref/interp2.html
http://gmt.soest.hawaii.edu/doc/5.1.1/grdsample.html
Operating on the principle of least surprise, I think we would like to impress (or at least not disappoint) users coming from other communities.
I did figure out that I can use interpolate.griddata() as a workaround, although it is roughly 2 orders of magnitude slower.  Here's what that looks like:
z = np.arange(0,16,dtype=np.float).reshape((4,4))
z[-2][0] = np.nan
z[-1][0] = np.nan
z[-2][1] = np.nan
z[-1][1] = np.nan
print z
x,y = np.meshgrid(np.arange(0,4),np.arange(0,4))
print x
print
print y
z = z.flatten()
points = np.zeros((16,2))
points[:,0] = x.flatten()
points[:,1] = y.flatten()
xi = np.arange(0.5,3.0,1.0)
yi = np.arange(0.5,3.0,1.0)
xi,yi = np.meshgrid(xi,yi)
xi = xi.flatten()
yi = yi.flatten()
xnew = np.zeros((len(xi),2))
xnew[:,0] = xi
xnew[:,1] = yi
zi = interpolate.griddata(points, z, xnew, method='linear')
print zi.reshape((3,3))

Marking this as easy-fix task (to add note to docstring that interp2d doesn't do NaN handling). When this is done, also needs to be done for related functions in interpolate.

Documentation has been updated in gh-6475, so closing. Thanks @smopucilowski , all.


Role Naming Convention Mismatch leading to ye ole Not Authorized to access iam graphql from lambda function

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
v16.16.0
Amplify CLI Version
9.2.1
What operating system are you using?
Arch Linux 5.19.2-arch1-1
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No manual changes made
Amplify Categories
function, api
Amplify Commands
update
Describe the bug
The role name created by autogeneratedParameters, ${appName}LambdaRole${shortId}, doesn't match the convention expected by getAdminRoles, ${r.resourceName}-${currentEnv} in amplify-category-api leading to the set of adminRoles in the Query.getModel.auth.1.req.vtl being incorrect.
cfn in lambda
 "LambdaExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "RoleName": {
          "Fn::If": [
            "ShouldNotCreateEnvResources",
            "myappLambdaRolee80f9b07",
            {
              "Fn::Join": [
                "",
                [
                  "myappLambdaRolee80f9b07",
                  "-",
                  {
                    "Ref": "env"
                  }
                ]
              ]
            }
          ]
        },

vs the vtl:
#if( $util.authType() == "IAM Authorization" )
  #set( $adminRoles = ["myfunction-testenv"] )

This is with the new "transformerversion": 2, and useexperimentalpipelinedtransformer": true
Expected behavior
I expect the two libraries to match conventions on role names.
Reproduction steps
I guess do the steps in https://github.com/aws-amplify/amplify-category-api/issues/679
GraphQL schema(s)

# Put schemas below this line

Project Identifier
No response
Log output

# Put your logs below this line

Additional information
No response

Hey @joekiller :wave: thanks for raising this! From the generated VTL resolvers we can see, as you noted, the adminRoles are constructed using the function's name, which is later verified by checking against the userArn of the caller's identity. When calling from a Lambda this ARN will include the ${functionName}-${envName} naming convention.
Are you receiving an unauthorized access from the Lambda or from the GraphQL API? The linked issue describes an issue where the grant our Lambda function access to the GraphQL API but the resolvers are not regenerated to reflect the new set of adminRoles (containing our newly created function)

@josefaidt thanks for the reply. I think I was getting unauthorized access when calling from the lambda function to a GraphQL endpoint. I'll double check this behavior and respond.

@josefaidt I renamed my lambda role and it seems to be working regardless per the recognition of the lambda name arn, not the role name itself. Thanks for clarifying the behavior. I'm guessing I ran into perhaps not having applied the permissions to the lambda via the cli. I forgot that, as documented in Working with Lambda execution environment credentials, that the lamda name is the "userName" provided to the authorizer so that makes sense.
I have a follow-up question though. If a lambda function within my environment is named via convention and given appropriate IAM permissions, is it sufficient to just include the Lambda name in "adminRoleNames" instead of the role name? The logic in the template seems to indicate that should be enough and I shouldn't have to worry about the name of the role unless it is fully outside of my account.
My confusion of chasing the role name stemmed from the documentation covering lambdas generated by the cli or functions not deployed by the cli. Grant Lambda function access to GraphQL API under "the Function deployed without Amplify CLI" indicates that functions outside the cli must have their role included in the "adminRoleNames" custom-roles.json however that seems inaccurate. It seems that "a function deployed without amplify cli must have it's name included in the custom-roles.json, not the role. Is this accurate?

Closing this issue, as the docs clarification has been merged.


Allow custom graffiti

Changes:

Add graffiti flag to allow the use of a custom graffiti

Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Other (please describe):

Testing
Requires testing

[x] Yes
[ ] No

In case you checked yes, did you write tests?

[ ] Yes
[x] No

Codecov Report

Merging #97 (636adf7) into develop (1d55f2b) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop      #97      +/-   ##
===========================================
+ Coverage    84.62%   84.66%   +0.04%
===========================================
  Files           32       32
  Lines         1854     1859       +5
===========================================
+ Hits          1569     1574       +5
  Misses         230      230
  Partials        55       55

Flag
Coverage Δ

unittests
84.66% <100.00%> (+0.04%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

cli/cli.go
68.90% <100.00%> (+0.39%)
:arrow_up:

internal/pkg/generate/generate_scripts.go
96.50% <100.00%> (+0.03%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


update GithubOrg from 'alexkappa' -> 'auth0'

closes #122
very new to pulumi provider development so not sure if this is everything that is necessary. Let me know if there is something I'm missing or if I need to regenerate the source

Hey @kevinschoonover
Thanks so much for the work here. I took this PR and then added a few things extra to it to make the PR upgrade to v0.27.1 of the auth0 provider - I have amended the commit to ensure your GitHub user gets the credit
Thanks so much for the work here! We REALLY appreciate it
Superceded by #127


Update app-governance-app-policies-create.md

@nearora-pm : Thanks for your contribution! The author(s) have been notified to review your proposed change.


add dbver & dbver.py

the whole database will be created by version 1.
so if there are existing data it will fail.
you can manually test and insert the correct version pointer into [dbver] if there is no difference between existing structure and version 1.
eg:
insert into dbver (repository_id, repository_path, version) values('redisctl', '/home/hblzxsj/svn/redis-ctl/dbver', 1);

Cool. Thanks for your effort.
Could you please squash those 2 commits into one, and check it with PEP8?

all have been done.
next I will add support for other proxy, how would you like supported by new type specification during proxy adding or just auto-detect?

I think it will be easier to understand by adding a program type column in the proxy table.

fine.
I will first try to add supporting for corvus.


add a signature and put on to the microsoft store

It's great. Wish the program be put on to the microsoft store and gain more popularity.

+1


review quality of resized photos

using qual 72 everywhere yields some pixelized thumbnails.  might need to adjust the qual setting based on the final res.

went through a number of tests, and quality of 88 seems to be a good setting for minimizing loss of image quality while decreasing file sizes.


Sui doc content issue or request and wallet bug

If this is an issue with existing content, provide the URL or GitHub path to the topic. Otherwise, use New.
Describe the issue or request. Provide as much detail as possible. For issues, it is helpful to copy the specific section of the topic into the issue.
Thank you for taking the time to let us know about the issue or request. We triage all new issues and requests within 2 business days. We will follow up if we need additional information.

walet has bug


URL Query Params are encoded due to buggy version of normalize-url

We currently use https://github.com/sindresorhus/normalize-url ^4.5.1 to normalize URLs and it's buggy.
The bug is simple that, they don't decode back the queryParameters after it's encode as side-effect of sort().
Fixed later here: https://github.com/sindresorhus/normalize-url/pull/158
Solution: Upgrade to newer version of normalize-url

There is one issue though, normalize-url went to Full ESM only in v7.0.0 and the issue was fixed in latest version i.e v0.7.3
cc: @visualjerk