text:
service without healthchecks don't receive dns entry (not clear if intended)

Output of docker version:
Client:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd
 Built:        Fri Jun 17 20:35:33 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   a7119de
 Built:        Fri Jun 17 22:09:20 2016
 OS/Arch:      linux/amd64
 Experimental: true

Output of docker info:
Containers: 125
 Running: 2
 Paused: 0
 Stopped: 123
Images: 236
Server Version: 1.12.0-rc2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 470
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge overlay null host
Swarm: active
 NodeID: 6o19rpi5kx93jt9z6osdxfwfp
 IsManager: Yes
 Managers: 1
 Nodes: 1
 CACertHash: sha256:5711d0745394ebace6e82caa93a943281c0ce201902d4c3b6ba0b12f5d13cb02
Runtimes: default
Default Runtime: default
Security Options: seccomp
Kernel Version: 4.4.13-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.954 GiB
Name: moby
ID: 2PNZ:QY46:DCR2:IAU7:WUU4:Q5FZ:MAVC:KK7U:6JKH:LG2L:ANYI:3JP6
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 107
 Goroutines: 281
 System Time: 2016-06-26T17:28:58.594609691Z
 EventsListeners: 32
No Proxy: *.local, 169.254/16
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8

mac beta
Steps to reproduce the issue:

docker service create --name dns_test --replicas=1  nginx:latest
docker exec -it  /bin/bash
ping dns_test

Describe the results you received:
root@b2e0ce1a5da7:/# ping dc_test
ping: unknown host

Describe the results you expected:
It should be a known host.
Additional information you deem important (e.g. issue happens only occasionally):
I'm not sure if this is intended because there is no health check, but either way it's currently not clear why there is no host. I'd imagine w/o a health check the status should always be OK. If a health check is required for a service then that should be made known somehow in the flow.

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS               NAMES
b2e0ce1a5da7        nginx:latest        "nginx -g 'daemon off"   2 seconds ago       Up 1 seconds              80/tcp, 443/tcp     dns_test.1.bnmkgsidlug1zwh7sdhmvnw7l
98f3a8a8ecb3        hc_test:latest      "nginx -g 'daemon off"   11 minutes ago      Up 11 minutes (healthy)   80/tcp, 443/tcp     web.2.bzpdiq8nuzzxdvdp0iyd4ynjt
d919e98214fc        hc_test:latest      "nginx -g 'daemon off"   13 minutes ago      Up 13 minutes (healthy)   80/tcp, 443/tcp     web.1.5dka4xamn4do07y1jsor7c9h

Also, since this is a service shouldn't the status be something even without a health check?

So, what's kinda strange is that the resolv.conf file had a 127.0.0.11 address iirc for another service that routed correctly https://github.com/docker/docker/issues/23965; however, my new containers have
root@a309e600e41b:/# cat /etc/resolv.conf
search local
nameserver 192.168.65.1

I'm not sure why the file is different across create calls.


text:
docker stack deploy lacks "--with-registry-auth"

There's currently no option to deploy a stack that's using private images. We should add a --with-registry-auth flag to docker stack deploy to allow this (was discussing with @vdemeester).
/cc @aanand @dnephin @vdemeester

I'm pretty sure that flag has been on stack deploy since 1.12

Oh my, lol, you're right, PEBKAC, we were discussing an error, then I was watching at the wrong output in my terminal.
Abort abort, ignore ignore

TL;DR there's no such thing as docker service deploy 😇

source: gharchive/issue

authors: dnephin thaJeztah

repo: docker/docker

license_type: permissive

license_source: github-api


text:
Add more verbosity options to docker build

Adds a new flag -v/--verbose that can take the following values :

build : hide RUN output (same as -q/--quiet)
run : hide all but RUN output
none : hide everything, and returns only the full image ID

The -q/--quiet option is kept and working as before, but -v/--verbose
takes precedence over it.
This is a try that kinda follows @duglin comments on https://github.com/docker/docker/pull/10921#issuecomment-75325000. This would close #13674. 🐸
Few notes though :

[ ] I don't really like --verbose as an option, but did not have inspiration :sweat:. Keeping only --quiet is hard though because changing it to a non-bool args would break current cli behaviour.
[ ] Few behaviours needs to be define — e.g. what should it print if the build is run with --verbose=none and fails.
[ ] Needs documentations updates.
[ ] Needs completion updates for bash/zsh/…

Signed-off-by: Vincent Demeester vincent@sbr.pm

You're not gonna like this but... I'd rather wait until we pull out the builder (cc @tiborvass) :crying_cat_face:

@icecrime :sweat_smile: I was guessing you would say that :stuck_out_tongue_closed_eyes: and it feels coherent with the /pulling out/ :wink: .

@vdemeester I think it's best to close this PR in the meantime. Please close yourself, because if I close it, you won't be able to re-open :-)

Oh, unless @tiborvass doesn't think it has to be closed, that is :-)

@thaJeztah you're right, I'll close this for now :stuck_out_tongue:

source: gharchive/pull-request

authors: icecrime thaJeztah vdemeester


text:
Add progressbar for docker load

Signed-off-by: Lei Jitang leijitang@huawei.com
Currently docker load just block until the docker load finish,
it's not friendly for user. This patch add progressbar for docker load.
$ docker load -i ubuntu.tar
Loading file to server [==================================================>] 225.5 MB/225.5 MB
Loading layer: 1c9383292a8f [==================================================>] 201.6 MB/201.6 MB
Loading layer: 9942dd43ff21 [==================================================>] 801.8 kB/801.8 kB
Loading layer: d92c3c92fa73 [==================================================>] 603.6 kB/603.6 kB
Loading layer: 0ea0d582fd90 [==================================================>] 601.6 kB/601.6 kB
Loading layer: cc58e55aa5a5 [==================================================>] 21.18 MB/21.18 MB
Loading layer: c4ff7513909d [==================================================>]   599 kB/599 kB
$

Oh, nice!!
Looks like there are go-lint failures though;
Errors from golint:
api/client/load.go:26:18: should omit type io.ReadCloser from declaration of var input; it will be inferred from the right-hand side

Please fix the above errors. You can test via "golint" and commit the result.

So do the docker save?

@HuKeping  The docker save progressbar is on working

but don't know if we really need this ..

The test failure seems related, please take a look: FAIL: docker_api_images_test.go:52: DockerSuite.TestApiImagesSaveAndLoad

Design seems ok for me
ping @docker/core-maintainers

@jimmyxian can you take care of this for the swarm side ?
Thanks

I like it, moving to code review

@vieux Thanks for ping me.
I will take care of this on swarm side. :)

@coolljt0725 Would you mind to address some comments?

@LK4D4, @coolljt0725 has been at DockerCon! :)

This will need a rebase after #17924, but I recommend waiting for #18353, which changes ProgressReader.

ping @coolljt0725, https://github.com/docker/docker/pull/18353 was just merged. can you rebase this and update this for the changes in https://github.com/docker/docker/pull/18353? Thanks!

@thaJeztah  Thank you for the ping, I'll update it later

ping @coolljt0725 :innocent:

@thaJeztah  Thank you for your ping. sorry for the delay to update this PR,  very very busy these day and maybe I can update this PR this weekend.

@coolljt0725 no worries! Let us know when you're done (or if you want someone to carry it for you)

ping @tonistiigi do you think somebody should carry this PR?

@thaJeztah  Sorry for the late, I start working on this...

@coolljt0725 thanks, thats great! And Happy New Year to you! (Well, "our" new year, I think your new year is in February :smile:)

@thaJeztah  Thank you, and Happy New Year to you(yes, Chinese New year is in Feb) -:)
I have finished the refactor and it works
$ docker load -i ubuntu1.tar
Loading layer: 17f5bb501870 [==================================================>] 201.6 MB/201.6 MB
Loading layer: 983647a7cf79 [==================================================>] 801.8 kB/801.8 kB
Loading layer: 6d8125b31a09 [==================================================>] 603.6 kB/603.6 kB
Loading layer: d351dc964d98 [==================================================>] 601.6 kB/601.6 kB
Loading layer: f146e528f86d [==================================================>] 21.18 MB/21.18 MB
Loading layer: d8b3f56cd852 [==================================================>]   599 kB/599 kB
But don't know why I can't push it to Github
$ git push -f origin add_load_progressbar
Username for 'https://github.com': coolljt0725
Password for 'https://coolljt0725@github.com':
Counting objects: 1233, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (259/259), done.
Writing objects: 100% (619/619), 143.65 KiB | 0 bytes/s, done.
Total 619 (delta 482), reused 477 (delta 356)

Don't know why it blocked. Maybe something wrong with the proxy....

@coolljt0725 that's weird. If it doesn't work, feel free to open a new PR to replace this one

@thaJeztah  It should be something wrong with our enterprise firewall, I'll take a look at that tomorrow, if it doesn't work, I'll try to open a new PR

Thanks @coolljt0725

updated. I wonder if we should add a flag to the load api to disable the progress bar

updated. I wonder if we should add a flag to the load api to disable the progress bar

Perhaps a -q / --quiet flag? Didn't we have detection to check if a TTY is present? I can imagine this not needed if ran from a script :)

@aaronlehmann  thanks you for your suggestion
@thaJeztah  Added a -q/--quite flag

@thaJeztah  Oh, my poor english..., thank you, updated

@coolljt0725 don't forget to update the docs and man-pages as well :innocent:

@thaJeztah  I'll update the docs when it go to docs review

@coolljt0725 you need to make a PR to https://github.com/docker/engine-api to put the API changes in (to be able to rebase there and proceed forward) :sweat_smile:

ping @vieux because they do this in swarm. Maybe they can remove their implementation if we add this one.

oh he's already in this thread XD

@calavera yes! as soon as it's merged we are going to switch to this one

SGTM

/ping @coolljt0725 :angel:

@vdemeester  will rebase later :)

rebased

good so far, just needs tests and doc updates.

LGTM

ping @coolljt0725 don't forget to update the documentation for the new flag/option

@thaJeztah Thank you for reminding :)

@coolljt0725 this is good but you can't update the files in vendor/ without vendoring them first.

@tiborvass  I'll update this once https://github.com/docker/engine-api/pull/65 merged

@coolljt0725 docker/engine-api#65 was already merged and vendored, go for it!

@calavera  rebased.
Chinese New Year is coming, Happy Chinese New Year  :-).
And I start a 9-day vacation tomorrow, so I don't know if I have time to update the tests
and docs during the vacation, if not, I'll update docs and test when the vacation end.

@coolljt0725 happy new year, and enjoy your vacation!

Here comes the  "Year of Monkey" LOL

:fireworks: :monkey_face: :fireworks:
we can carry it.

@coolljt0725 happy new year!!! and thanks

LGTM

Carried here: #20078

authors: HuKeping LK4D4 aaronlehmann calavera coolljt0725 cpuguy83 duglin endophage jimmyxian thaJeztah tiborvass vdemeester vieux


text:
Add hint of progress to the output of docker build

- What I did
This fix tries to address the issue raised in #24912 where docker build only consists of the current step without overall total steps.
- How I did it
This fix adds the overall total steps so that end user could follow
the progress of the docker build.
- How to verify it
An additonal test has been added to cover the changes.
- Description for the changelog
Add hint of progress (e.g., Step 1/5) to the output of docker build so that the total steps is known during the build progress.
- A picture of a cute animal (not mandatory but encouraged)
This fix fixes #24912.
Signed-off-by: Yong Tang yong.tang.github@outlook.com

This change breaks compatibility for those who greps the stream with a regexp like Step ([0-9]+) :.
So I think "Step 1 : FOOBAR (1/5)" is better for compatibility.

ping @duglin wdyt?

At first I thought we'd have to turn the Dockerfile processing into a phase 2 thing, so I'm glad that I forgot that we read it all into memory and can know the number of steps easily.  I'll try to find some time over the next day or so to review it.  But, overall, I don't have an issue with the idea of doing this, I just personally don't see much value in it, but if others do it might help to have them explain why this would help aside from "just to know".

I just personally don't see much value in it

Yeah, it won't give any clue as to how long the remaining steps will take, so it's not adding a lot, other than you know how many steps it takes until completion

Perhaps instead just print out the "Total Steps" right at the start?
ie:
$ docker build .
Sending build context to Docker daemon 8.192 kB
Total Steps: 9
Step 1 : FROM alpine:3.4
...
Step 9 : CMD sh
 ---> Running in 2c2a1c7f3aa1
 ---> fdbc4e5a9e55
Removing intermediate container 2c2a1c7f3aa1
Successfully built fdbc4e5a9e55

I have a slight preference for the Step x/y form, just so I don't have to scroll up to see the total.

I agree with @duglin

moving this to code review

LGTM

LGTM

authors: AkihiroSuda duglin thaJeztah tianon yongtang


text:
[WIP] Synchronous service create and service update

Change "service create" and "service update" to wait until the creation or update finishes, by default. Show progress bars for the overall operation and for each individual task (when there are a small enough number of tasks).
Using -d or --detach will cause the old, asynchronous behavior.
Using -q or --quiet will make the commands still wait for the creation or update to complete, but without outputting progress information.
In its current state, this is hacky and still needs some work. The remaining work falls in two categories:
Internals:

[ ] The current implementation is polling. It would be much better to use the Swarm events API once it's ready (@dongluochen).
[ ] The task endpoint spec is not included when evaluating if a task is up to date. This structure isn't exposed through the REST API, so it would need to be added (or we need to come up with a better way of checking if a task is up to date).
[ ] The method of checking for global service convergence is a terrible hack. The constraint evaluator was ported to the client so it can tell which nodes match the constraints. This needs to be redone in a better way.
[ ] Handle rollback update states (once #31108 is merged)

Cosmetic/UX:

[ ] The progress bars show numbers like "9B/9B", assuming the units are bytes. This should be changed to drop the "B" suffix.
[ ] Upon ^C, the command should print a notice that the creation or update is still continuing in the background.
[ ] Possible visual improvements: line up progress bars, etc.

cc @docker/core-swarmkit-maintainers @tiborvass @anusha-ragunathan

Demo: https://asciinema.org/a/4btgvuk1dv3z8zn0y882gqph5

@aaronlehmann what happens if the service created can't be scheduled, because of constraint that cannot be fullfilled for example ? How should it behave ?

I like the feature but it would be a huge breaking change. It feels a bit like the docker-compose up vs docker-compose up -d debate.
I can see use-cases for this, but should we also attach to the service logs after the service was deployed (like docker-compose up)?
Let me add this to the next maintainers meeting to get more eyes / open the discussion

what happens if the service created can't be scheduled, because of constraint that cannot be fullfilled for example ? How should it behave ?

You would see one or more of the tasks stuck at "pending". This synchronous mode gives visibility into the problem, which would otherwise require a "service ps" command to notice.

You would see one or more of the tasks stuck at "pending".

Would it output the error messages  / reason for being unable to deploy the task?

Not at present, but that's definitely possible.

+1 for the feature, -1 for changing the default immediately.
I think we need to put it behind a flag for now. We can add a warning when no flag is used, and change the default in a release or two.
Changing the default is going to break people who use this command in scripts.

We should also look at this for docker stack deploy, to show progress, and ideally show logs as well for a stack (to be more like docker-compose)
We discussed this in the maintainers meeting, and like the feature, but (for now) to not be the default.

Huge +1
It's also going to "fix" the workflow for many people that currently do a service create then just a bunch of service ps and then have to inspect tasks to figure out what happened.
Or worse - people that just do service create. Contrary to docker run, a service is not immediately ready and service creation is fully asynchronous. So the service is not responding, the port doesn't work, and the rollout may have failed.
UX Feedback:

Everything should be aligned. I think the state should be padded to the longest possible value so the progress bars don't "shift" to the left/right when the state changes
What's the XB/XB at the end?
Waiting to verify that tasks are stable - this is a bit non obvious, some rewording might help. Also, could we have a countdown? e.g. Waiting X seconds
Not sure if overall needs its own progress bar. By definition it has a slightly different meaning than the others. On first look it seems like a slow task. Maybe plan text would be better, e.g. Updating service <foo> (2 out of 12 completed)
What's interesting is error handling here. Could you link to a demo? I think the interesting bits of information are the overall status (the one in UpdateStatus - which I think should be part of the first line), the task error (can we show it somewhere?) and the rollback/pause status
When the user Ctrl-C's the deployment, we should say that it's continuing in the background
When we rollback, we should print the error message etc
When we pause, we should say why and how to continue

Looks amazing so far!

Looks awesome.

Should Ctrl-C rollback the deployment?
I think this going on by default might be too much, but an --interactive flag sounds good.

I'm with @dnephin: huge 👍, but I wouldn't change the default.

Nice work!
Regarding re-usability of the service progressbar for other clients that potentially want to display service updates (eg, plugin install), it is better to extract cli/command/service/progress.go into a separate package.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "synchronous-service-commands" git@github.com:aaronlehmann/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842355079112
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Thanks for all the comments. I've updated this to address the feedback. Details below, and new demo here: https://asciinema.org/a/9f9rgk0e7fczkxi5vfu7yofmw

I think we need to put it behind a flag for now. We can add a warning when no flag is used, and change the default in a release or two.

I've changed the behavior so the default is unchanged, and the -i / --interactive flag is required to see progress info. One thought I had is that if we only enable this by default when the command is running on a TTY, it's less likely we would break scripts. But I'm also okay with putting this behind an option, for now. It also means there's less urgency in fixing the technical implementation issues described in the PR description (though I would like to fix at least some of them before merging).

Everything should be aligned. I think the state should be padded to the longest possible value so the progress bars don't "shift" to the left/right when the state changes

Done.

What's the XB/XB at the end?

This was an artifact of the progress bar code. I've now added an option that suppresses it.

Waiting to verify that tasks are stable - this is a bit non obvious, some rewording might help. Also, could we have a countdown? e.g. Waiting X seconds

Changed this so it has a countdown now.

Not sure if overall needs its own progress bar. By definition it has a slightly different meaning than the others. On first look it seems like a slow task. Maybe plan text would be better, e.g. Updating service  (2 out of 12 completed)

Changed to plain text

What's interesting is error handling here. Could you link to a demo? I think the interesting bits of information are the overall status (the one in UpdateStatus - which I think should be part of the first line), the task error (can we show it somewhere?) and the rollback/pause status

Demo linked above. I've done some more testing and refinement of this now. Unfortunately it's not especially straightforward to show the task error, because the ID of the task that paused an update is inside a textual message. But we can figure something out if this would be a big usability win.

When the user Ctrl-C's the deployment, we should say that it's continuing in the background

Done

When we rollback, we should print the error message etc

Blocked on #31108

When we pause, we should say why and how to continue

It says why. I'm not sure about the "how to continue" part. Any suggestions for what the message should say?

Regarding re-usability of the service progressbar for other clients that potentially want to display service updates (eg, plugin install), it is better to extract cli/command/service/progress.go into a separate package.

Moved to github.com/docker/docker/cli/command/service/progress.

It says why. I'm not sure about the "how to continue" part. Any suggestions for what the message should say?

docker service update <foo> should continue the paused deployment right?
Regarding the verification time - how are we picking the 45 seconds?
Also, is this looking at task status or update status? As in, do we take into account the rollback threshold?

docker service update <foo> should continue the paused deployment right?

Yeah, but I'm not sure we want to recommend that, because usually there's an underlying problem that should be fixed.

Regarding the verification time - how are we picking the 45 seconds?

I set --update-monitor 45s when I created the service, to demonstrate failures (by manually stopping some containers). The default is 5s.

Also, is this looking at task status or update status? As in, do we take into account the rollback threshold?

Sort of a mix of both. Basically, if the update pauses or rolls back, we'll see that in the update status. But the progress bars and countdown are driven by task status.

Looks great :)
Do we have some CLI designers in the house? @dnephin feedback?

Design LGTM

Hi
Is it possible to manage "docker service rm" action too ?
And what about "docker stack deploy/rm" command which launch multiple "docker service" actions ?
Thanx for reading

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "synchronous-service-commands" git@github.com:aaronlehmann/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842355076536
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

I've updated this to check which tasks are up-to-date on the manager side (using a task filter), rather than using the incomplete check I had implemented in the client which couldn't consider Endpoint. This checks one item off the to-do list.
The only remaining thing that I think should block merging this is finding a better way to enumerate relevant nodes for global services. I have a similar idea for how to handle this.

I found a way to avoid evaluating constraints in the client. Instead of computing how many nodes are eligible to run the service, it now takes the set of nodes seen referenced by up-to-date tasks. This is a reasonable proxy for computing that set directly.
I think the major issues have been resolved, and this is ready for code review and possibly merging. Avoiding polling would be nice, but that won't be possible for awhile. I think having an initial version that relies on polling is acceptable, particularly since this feature is activated by a flag rather than being the default.

Test failure should be resolved by #31535

Rebased and updated to report progress of rollback operations.
Here's an example of what the progress output looks like from a failed update that gets rolled back:
overall progress: rolling back update: 5 out of 5 tasks
1/5: running   [==================================================>]
2/5: running   [==================================================>]
3/5: running   [==================================================>]
4/5: running   [==================================================>]
5/5: running   [==================================================>]
rollback: update rolled back due to failure or early termination of task snr2t11e0t2t6lyzd6ule07rq
verify: Waiting 1 seconds to verify that tasks are stable...

PTAL. Should be ready to go unless there are suggestions for tweaks.

Rebased
Review ping

Small concern: -i / --interactive conflicts with docker container create --interactive.
-I?
Perhaps --progress (but -p is a big no no).
--wait? Although -w is taken as well (workdir)
Anyone, suggestions?

--foreground, --synchronous, --atomic, even --attach (as antonym to
proposed --detach).
On 20 Mar 2017 21:44, "Andrea Luzzardi" notifications@github.com wrote:

Small concern: -i / --interactive conflicts with docker container create
--interactive.
-I?
Perhaps --progress (but -p is a big no no).
--wait? Although -w is taken as well (workdir)
Anyone, suggestions?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/pull/31144#issuecomment-287891518, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ-oUBqWQq5ZYU7Jb6STzeslRHZrlHZks5rnuUcgaJpZM4ME8oJ
.

--foreground, --synchronous, --atomic, even --attach (as antonym to
proposed --detach).

Thanks!
--synchronous / -s wouldn't conflict with anything docker container related.
(-f in foreground is typically reserved for force in docker, it's not really atomic, and there's a docker attach command which might be confusing for --attach)

I'm not a fan of --synchronous (even though I used the word in the title of this PR. The term makes sense for programmers but not so much for non-programmers.

--await-completion/-c, --quiescence/-q...

--return-result/-r

Frankly,thee use case I need this for the most is scripting, not the interactive progress update (however neat :smiley:), similar to either docker run without --detach, or with --detach followed by either docker wait $id or docker logs -f $id depending on the situation. --progress or --interactive does not fit so nicely with that...

The naming sure is a pain. -i / --interactive probably isn't right, not only because it might be confused with docker run --interactive, but also because progress bars aren't actually interactive. --wait doesn't feel quite right to me, and -w is already taken.
Some daemons have options like -d / --dont-detach. That's not really right here either because this is a client command, not a daemon.
How about -P / --progress, with a separate, mutually exclusive --wait option that waits but does not show progress. This feels most intuitive so far to me. The main downside is that it doesn't match the --quiet pattern used by most other commands (--progress --quiet seems contradictory - I don't think we should allow it). Note that rsync has a -P / --progress flag.

-P is --publish-all in docker run/docker create.

If naming consistency is important, the option should really be --detach=false with default value true. That would be most consistent with other docker commands, especially docker create and docker run, which are the commands most users will probably come from and expect likeness with.

I'm liking --detach=false / -d=false, and -q --quiet for the flags. I think that will eventually allow us to transition to defaulting to -detach=false. and the -d flag will work like docker container run.

Switched to --detach=false. Also squashed commits.

Also changed the progress bars to move backwards when rolling back (cc @aluzzardi).

:/
While I like the philosophy of -d=false, it's a PITA to type every time.
We didn't make this the default behavior and now it's a flag that needs to be turned off manually.

I think that will eventually allow us to transition to defaulting to -detach=false

When? I don't see what's going to make it easier to transition to this in the future rather than now

When? I don't see what's going to make it easier to transition to this in the future rather than now

In this release we add a WARN: In a future release -d=false will become the default for any service create/update that doesn't explicit set a -d
In either the next release or one after we change the default and remove the warning.

When? I don't see what's going to make it easier to transition to this in the future rather than now

I discussed this with @aluzzardi and @thaJeztah. It seems like the general policy would be to make a note in docs/deprecated.md, then flip the default in 3 stable releases, which would be about a year from now.
My sense is that a year is probably too long to wait. I don't think this extra time helps people prepare; rather it just lets the existing default get further entrenched. Intuitively waiting 1 or 2 stable releases feels right to me. Is it possible for us to make an exception to the general policy, since this is not really a deprecation (more of a change in behavior)?

Discussed in the maintainers meeting: We can keep it for 1 release, and based on feedback decide to keep it for 1 more release.
We can do a follow-up PR / issue to make it configurable in the CLI configuration file, but can decide on that one if we want it

Thanks for discussing it. Do you want me to add a warning to the CLI when -d is not specified? What should the warning communicate?

My suggestion was something like this: "In a future release --detach=false will become the default"

I've added warnings when the flag is not specified.
For example:
Since --detach=false was not specified, tasks will be updated in the background.In a future release, --detach=false will become the default.

PTAL
@aluzzardi: Are you okay with moving forward with this given the plan put forward here? https://github.com/docker/docker/pull/31144#issuecomment-290496884

I just realized that --detach / -d is also an option on docker run; if we want to reuse that flag in future to implement --interactive / -i and --detach options for docker services, similar to the way docker run works, we should consider using a different name for this flag to prevent it becoming ambiguous.

The consensus so far seems to support --detach specifically because it's most consistent with docker run: https://github.com/docker/docker/pull/31144#issuecomment-288165223
I don't see a potential conflict between docker run --detach and docker service create --detach. It wouldn't really make sense for a service to remain "attached" to the terminal for the life of the service. There is not necessarily a single container to attach to; there may be many replicas. In the context of a service, --detach meaning to detach after convergence makes sense. At worst there's potential for confusion because the run flag and service flag won't behave the same way. But the other flag names proposed so far have their own downsides as well; I don't think there's a perfect answer.
I don't have strong feelings about the naming, but it's proving difficult to find a flag name that's acceptable to everyone. The discussion has already been going on for a few weeks.

@thaJeztah What differences do you see between this -d flag being added to service commands, and the -d flag on run ? I think they are the same idea, so we would use the same flag for consistency.
-i doesn't really relate to -d in any way that I can tell.

I agree with @dnephin I think see how -i and -d are related. If you do not specify -d you're attached, whether or not you have -i
I'm 👍 on --detach

If there's no ambiguity, then all is fine (sorry, I meant to reply sooner). Just wanted to make sure we didn't overlook anything

Thanks everyone!

Is there a lil asciinema or GIF of this?

@nathanleclaire: https://asciinema.org/a/9f9rgk0e7fczkxi5vfu7yofmw (slightly out of date, but mostly the same as what was merged)

Hey guys, per @vieux request Play With Docker has been updated with this patch. You can play with it there. Let me know in case you need me to change anything.

@aaronlehmann Great to see this merged 👍 Is there going to be a follow-up for docker service scale? I know that I can do docker service update --detach=false --replicas=5, but docker service scale allows scaling multiple services more than one service at a time, which is potentially a more complex operation to show than updating a single service.
Also, a minor detail: --replicas 5, --name my_service, etc. work, but --detach false does not; only --detach=false. Is this intentional?

but --detach false does not

Could it be that (because false is a built-in / shell command), that the shell evaluates false if there's no = in between?

@theJeztah No, that would require me putting false inside backticks or a subshell. I haven't checked if the --disable-content-trust argument to e.g. docker run behaves the same, but I don't see why it should.

@sirlatrom interesting; could you open an issue for that, so that it can be looked into? It should be either fixed, or at least documented

@theJeztah I believe this is how the go flags package (or whatever is being used in the Docker CLI) works, so it's really just working as designed. The --interactive/-i and --tty/-t flags to docker run work the same way, and one can specify e.g. --interactive=false (which is the default in that case).

It's because boolean flags can take an optional argument. --name requires an argument, so in --name my_service, my_service can be assumed to be the argument. But --detach is valid on its own, so false could be an entirely separate argument.

@marcosnils Cool!

This looks great, thank you.
Just a quick one if anyone is aware - are there any plans to integrate this with
docker stack deploy
which in a nutshell creates/updates a collection of services?
Thanks again!

@ozlatkov see https://github.com/moby/moby/issues/32367

@thaJeztah  - Thank you.

authors: GordonTheTurtle WTFKr0 aaronlehmann aluzzardi anusha-ragunathan diogomonica dnephin icecrime marcosnils nathanleclaire ozlatkov sirlatrom thaJeztah vdemeester vieux


text:
gremlin-server error

Tag latest not found in repository docker.io/htaox/gremlin-server

This is working as expected - If you look at the gremlin-server list of tags, latest is not one of them:

authors: FrenchBen isamuelson

repo: docker/kitematic

license_source: bigquery


text:
error

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

No information provided or steps to replicate - Closing

authors: FrenchBen comlanjunior


text:
Failure when creating Hello world docker

Expected behavior
for it to connect and work
Actual behavior
(HTTP code 401) unexpected - {"message":"Get https://registry-1.docker.io/v2/kitematic/hello-world-nginx/manifests/latest: unauthorized: incorrect username or password"}
Information about the Issue
I believe I have the correct password and username
Steps to reproduce the behavior

...Create the Hello World Doc
...Comes up immediately

Nevermind...I fixed it by logging in with my username instead of my email address.

closing issue


text:
c

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

docker

error

?

???

No information provided or steps to replicate - Closing 😞


text:
error pulling image configuration: Get https://dseasb33srnrn.cloudfront.net/registry-v2/docker/registry/v2/blobs/sha256/04/04b1e77dd57542e6892900293319157c844d94bf06d1aa62c9a86c033437ad6c/data?Expires=1525750435&Signature=F32fjn9HV1bHpquW39vxPv7UvpyMyXiV~wPaBkcmuJlg6gyRMwq3v-iJrqFJekysKRitAELUr8QsJSSTm7cq0w5sv4khekZOD06AYvgLeYshEZtWXSfMxsS1u-rjp6Z8cQGKCvc7IupU45AYcV472Y4idwa0OEAnuQ7f70fu~gc_&Key-Pair-Id=APKAJECH5M7VWIS5YZ6Q: net/http: TLS handshake timeout

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

that problem fixed now?
I meet the same problem


text:
Add Installation step for Libcompose Developers

Add Installation step for Libcompose Developers
Signed-off-by: Bo Hai bohai@huawei.com

Related issue: https://github.com/docker/libcompose/issues/32

ping @aanand @aduermael @ibuildthecloud  @gdevillele

Not sure I see the point of this versus just running make binary. (Though I find it strange that that builds all binaries by default.)

As @aanand said, not sure this is that related with #32 issue : the issue basically says "we can't do go get github.com/docker/libcompose and have something that work as there is dependencies to the non pkg packages that depends on the dockerversion generated code".

@aanand vdemeester
I think godep is not necessary.
In fact we only need to setup godep path to GOPATH.
Then we can use "go build" command to get the cli binary.

@bohai true, but https://github.com/docker/libcompose/issues/32#issuecomment-131998164 is all about the fact we currently can't use it because it depends on stuff that depends on docker/docker/autogen package.
But you're right, we might even need godep (especially in the Dockerfile).

so what do we do with this PR?
Do some of you think we should wait for #32 to be solved?

@gdevillele I think it's nice to have something about "How to build libcompose without docker", and this PR would be the answer to that (with little changes). I think #32 will take quite some time to be fixed so we definitly should not wait :wink:.
So either we want something about "How to build libcompose without docker" and we could merge this, either we don't and we should close it. :sweat_smile:

I'm -1 on this. I think if we're going to document a workflow it should be the make+docker workflow, not one that runs on the host.

@bohai thank you for the PR, but I'm gonna close this one for now. When #32 is handled it's not gonna needed anymore, and if we move away from godep (which is gonna be likely the case)
Feel free to comment if you think it should be re-open and re-discussed.

authors: aanand bohai dnephin gdevillele vdemeester

repo: docker/libcompose


text:
docker-machine activate

The current syntax for activating a docker-machine is not very intuitive.  Could we add a shortcut to be more in line with the other docker commands or other type of virtual environment commands?
currently, the way to activate a docker-machine is:
eval $(docker-machine env [machine-name])
Could we change this to something more like
docker-machine activate env
?

A child process can't modify the parent's environment, so any such command simply wouldn't work.

authors: djchou shin-

repo: docker/machine


text:
azure driver - create - Error with pre-create check: "unexpected EOF"

On docker-machine version 0.15.0 (binaries and GoLang libraries), using azure driver, machine create ends up with 'unexpected EOF'.
section of the related debug logs below

(docker-machine-lib-test113) DBG | Already registered for "Microsoft.Compute"
(docker-machine-lib-test113) DBG | Already registered for "Microsoft.Network"
(docker-machine-lib-test113) DBG | Already registered for "Microsoft.Storage"
(docker-machine-lib-test113) DBG | Docker port is configured as 2376
(docker-machine-lib-test113) DBG | Swarm host is not configured.
(docker-machine-lib-test113) DBG | Total NSG rules: 2
(docker-machine-lib-test113) DBG | panic: runtime error: invalid memory address or nil pointer dereference
(docker-machine-lib-test113) DBG | [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x9eca36]
(docker-machine-lib-test113) DBG |
(docker-machine-lib-test113) DBG | goroutine 24 [running]:
(docker-machine-lib-test113) DBG | github.com/docker/machine/drivers/azure.(*Driver).PreCreateCheck(0xc420286000, 0xc42017b300, 0xc42017b320)
(docker-machine-lib-test113) DBG |        /go/src/github.com/docker/machine/drivers/azure/azure.go:316 +0x146
(docker-machine-lib-test113) DBG | github.com/docker/machine/libmachine/drivers/rpc.(*RPCServerDriver).PreCreateCheck(0xc42017a880, 0x1efbc38, 0x1efbc38, 0x0, 0x0)
(docker-machine-lib-test113) DBG |        /go/src/github.com/docker/machine/libmachine/drivers/rpc/server_driver.go:201 +0x33
(docker-machine-lib-test113) DBG | reflect.Value.call(0xc420086720, 0xc420178338, 0x13, 0x141760a, 0x4, 0xc42006ff18, 0x3, 0x3, 0xc42007a040, 0x0, ...)
(docker-machine-lib-test113) DBG |        /usr/local/go/src/reflect/value.go:447 +0x969
(docker-machine-lib-test113) DBG | reflect.Value.Call(0xc420086720, 0xc420178338, 0x13, 0xc420051718, 0x3, 0x3, 0x0, 0x0, 0x0)
(docker-machine-lib-test113) DBG |        /usr/local/go/src/reflect/value.go:308 +0xa4
(docker-machine-lib-test113) DBG | net/rpc.(*service).call(0xc420170d80, 0xc4201720f0, 0xc4200328d0, 0xc4200328e0, 0xc420189580, 0xc42017ae80, 0x104fea0, 0x1efbc38, 0x16, 0x104fea0, ...)
(docker-machine-lib-test113) DBG |        /usr/local/go/src/net/rpc/server.go:384 +0x14e
(docker-machine-lib-test113) DBG | created by net/rpc.(*Server).ServeCodec
(docker-machine-lib-test113) DBG |        /usr/local/go/src/net/rpc/server.go:480 +0x43a
Error creating a machine:  Error with pre-create check: "unexpected EOF"
Making call to close driver server
(docker-machine-lib-test113) Calling .Close
Failed to make call to close driver server: connection is shut down
Making call to close connection to plugin binary

same issue with v0.16.0


text:
How to get newest docker engine on MacOS with open-source Docker?

After installing both docker and docker-machine from Homebrew and setting up docker-machine with a VirtualBox driver, the docker version command reports that my client version is 20.10.8 whereas the server version is 19.03.12.
I would like to upgrade to the latest server version (20.10.8 at the time of posting), that should still be open source if I'm not mistaken.
As it appears that docker-machine is not actively maintained anymore, what is the correct way to upgrade to the latest docker server version (without using proprietary Docker software)? Are there any instructions anywhere? Thanks

Version 19.03 is indeed the last and final version of boot2docker, the Linux distribution of Docker machine. It is now deprecated
You can use an Ubuntu VM and install and upgrade Docker in it, but docker-machine only does this for cloud drivers (and doesn't support 20.10)

Like so: https://boot2podman.github.io/2020/07/22/machine-replacement.html
You could use another virtualization solution, by doing the same commands as in the Vagrantfile... The docker client (installed with brew) uses ssh to talk to the socket in the VM.

examples docker-machine with vagrant.
<example>/
|__ Vagrantfile
|__ docker-compose.yml ... example for docker container(php:apache).
|__ index.php          ... example php source.

Vagrantfile
Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/hirsute64"

  config.vm.network "private_network", ip: "192.168.33.10"

  # mapping working dir to to vm as same path.
  config.vm.synced_folder ENV["PWD"], ENV["PWD"]
end

docker-compose.yml
version: "3"
services:
  php:
    image: "php:apache"
    volumes:
      - ".:/var/www/html"
    ports:
      - "80:80"

index.php
<?php
phpinfo();

launch vagrant vm.
vagrant up

register to docker-machine with generic driver.
docker-machine create --driver generic \
	       --generic-ip-address "192.168.33.10" \
	       --generic-ssh-key $PWD/.vagrant/machines/default/virtualbox/private_key \
	       --generic-ssh-port 22 \
	       --generic-ssh-user "vagrant" \
	       docker-with-vagrant-vm

apply docker-machine environment variables.
eval $(docker-machine env docker-with-vagrant-vm)

list docker machines.
docker-machine ls
NAME                     ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER      ERRORS
docker-with-vagrant-vm   *        generic      Running   tcp://192.168.33.10:2376            v20.10.8

launch docker container.
docker-compose up -d

open browser.
open http://192.168.33.10/

Nice! I was thinking to do a vagrant-machine to wrap it (Vagrant), but in retrospect a Vagrant machine-driver would have been better...

Here is another project that I'm following closely: https://github.com/abiosoft/colima
It is the most promising Docker Desktop replacement for Mac I have seen and I have had the most success with it so far.

authors: afbjorklund kumikumi lfoalpha


text:
Add flexible JSON dump debugging method

Hey @ehazlett @sthulb lately I've been using this function to get a closer peek at what's going on behind the scenes in arbitrary data structures.  I find that it's really really helpful to check that your structs have values that are in alignment with what you think you're getting back.  Can we have it please?
Signed-off-by: Nathan LeClaire nathan.leclaire@gmail.com

I'm indifferent. I will say that go already has: fmt.Printf("%#v", var) which will do something similar, but will add types to the output.

LGTM

:tada: :balloon: :clap:

authors: ehazlett nathanleclaire sthulb


text:
Fix some typos in secrets

Signed-off-by: kevinetc123 kaiwentan@harmonycloud.cn

LGTM

repo: docker/swarmkit


text:
Version service specs

Adds fields to Service and Task that keep track of a version number for ServiceSpecs. This version number is different from the service object version (which is tied to the Raft index).
Then change the scheduler to use this, instead of marshalling the specs to compare them (which didn't work reliably).
Also make the orchestrator use SpecVersion as an optimization, when available.
Note this versioning is not used by the API at this point. It's a purely internal thing.
Supersedes #1392
cc @aluzzardi @dongluochen

@aluzzardi: We were discussing earlier about why SpecVersion doesn't use a Version type, with the version of the service which the spec comes from. One reason is that controlapi wouldn't know what to set here. It has to include SpecVersion when it updates the service, but the updated version information for the service won't be available until after it updates the service. We could use the version number of the service from before the spec is changed, but I feel that this would be confusing. People might try to compare SpecVersion to service.Meta.Version, and they would find that it never matches as expected.
For this reason, I think it's better to use an independent versioning scheme for SpecVersion. And if we're not using Raft indices, we shouldn't use the Version type, which implies a connection to Raft.

Can we put spec_version for a service inside of ServiceSpec? Then you don't need tracking like this.

If we did that, it would be under the user's control, which I don't think makes sense.

LGTM

Rebased

Updated to use the Version type for SpecVersion, per a discussion with @aluzzardi. Note that the spec version will get the service's version number from before the new spec is put in place. Thus, the SpecVersion and service Version, won't match, but will always be one generation apart. The upside of doing this is that we can use the same type instead of inventing a new one for spec versions or using bare integers.
ping @aluzzardi @dongluochen

LGTM
Maybe we should use versions for the control API filter

authors: aaronlehmann aluzzardi dongluochen


text:
Don't delete tasks until they're actually removed by the agent

This PR is a proposed way to fix https://github.com/docker/swarmkit/issues/2407. We may choose to solve the same problem differently, but here's what this PR does:

Add a new task state called REMOVE.
On service removals or scale downs, tasks that are due to be removed get updated to have desired state REMOVE (as opposed to just straight up deleting them like the existing behavior. This existing behavior causes networking issues as detailed in #2407, and also reporting issues such as https://github.com/moby/moby/issues/34967).
The agent detects desired state REMOVE and initiates task shutdown.
The task reaper deletes tasks that have desired state REMOVE and actual state >=SHUTDOWN

Things this PR does not deal with

Changing API output (do we want to be able to do docker service ps and see tasks in REMOVE state until they're deleted? What about scale downs?)
Updating the design docs

@nishanttotla As I stated in the other issue, adding a new state for removal doesn't make a whole lot of sense. There is already the functionality of removing the task from the assignment set that activates the removal workflow. We can tell that this state is unnecessary, because it is just a noop on the agent and no actual removal is happening. States are meant to set a target for a state and then the agent achieves that target.
The main problem that is addressed here is that the orchestrator needs to confirm shutdown (some sort of ack) before releasing the ip address to another container. If a task is reported as COMPLETED or SHUTDOWN, the ip address should be released. However, it seems we remove tasks before confirming their final state and that is likely the root cause of the bug.
What I am not understanding with this PR is why you think you need a removal state. From the changes to the agent, it is clear that the shutdown (or completed, if it is already down) state is sufficient.
The correct solution here is to remove these tasks from the assignment set, so they are not sent down to the agent. The agent will proceed with the remove. You can see part of this logic here. If you want acknowledgement of cleanup, you don't need to do this. Simply set the target state to shutdown, and the task will get shutdown and release resources (like ip address). You may also be able to use the existing ORPHANED or DEAD desired state to signal the task reaper to actually remove the task.
Before proceeding with a PR, it would be good to fully complete the design discussion so that we can find a proper solution.

@stevvooe @nishanttotla why do we need to remove from the assignment set? why is it not sufficient to simply set the task state to "shutdown", then let the task reaper clean up the task when it gets reported as shutdown?
Here is a quick diff of what I'm talking about. No tests, not sure it even builds, just trying to convey the idea:
https://github.com/docker/swarmkit/compare/master...dperny:sequential-task-removal

Ah, I see, Slot doesn't work like that.

Updated the diff of my counterproposal. Check if all tasks in a slot are dead, and, if so, delete all the tasks in that slot.

why do we need to remove from the assignment set?

I am not sure that it is necessary, either. I was trying to communicate that "removal" is proxied through removal from the assignment set. Looking at this closer, having shutdown confirmation seems like the first step (which I hope is already working).
It seems like the missing component here is acknowledgement that the allocator has returned the tasks resources to the pool before removing the task.

Based on our offline discussion, I'm going to hold off on updating the state name until we all can agree on it. In the meantime, I'll make sure this PR works right.
I'll also make sure I update design docs as an immediate follow up.

I've address most of the above comments.

i'm gonna carry this PR to completion for @nishanttotla because he's not available right now.

authors: dperny nishanttotla stevvooe


text:
fullscreen implementation on bindable input

Please review the PR for fullscreen implementation on the component. Check the exit arrow design.
If you are happy, merge it,
If not, let me know what I can do.

@jaysaikia got my laptop back, I will be reviewing this tonight. In the meantime, what do you think about an implementation more like this? Perhaps your implementation could be a fallback if fullscreen isn't supported. (I will just add it when merging)
Note: this is abridged so doesn't include any checks from ngOnDestroy, etc.
...
get isFullscreen() {
    return this.document.fullscreenElement ||
      this.document.webkitFullscreenElement ||
      this.document.mozFullScreenElement ||
      this.document.msFullscreenElement;
  }

enterFullscreen() {
    if (this.container.nativeElement.requestFullscreen) {
      this.container.nativeElement.requestFullscreen();
    }
    else if (this.container.nativeElement.mozRequestFullScreen) {
      this.container.nativeElement.mozRequestFullScreen();
    }
    else if (this.container.nativeElement.webkitRequestFullscreen) {
      this.container.nativeElement.webkitRequestFullscreen();
    }
    else if (this.container.nativeElement.msRequestFullscreen) {
      this.container.nativeElement.msRequestFullscreen();
    }
  }

exitFullscreen() {
    if (this.document.exitFullscreen) {
      this.document.exitFullscreen();
    }
    else if (this.document.mozCancelFullScreen) {
      this.document.mozCancelFullScreen();
    }
    else if (this.document.webkitExitFullscreen) {
      this.document.webkitExitFullscreen();
    }
    else if (this.document.msExitFullscreen) {
      this.document.msExitFullscreen();
    }
  }

@dockleryxk Thanks for merging this. Was busy last few days at work.

@jaysaikia no problem. Still curious about your thoughts on using the browser fullscreen functionality

@dockleryxk I think it is a straight forward implementation, but I believe not all browsers are compatible at the moment, esp iOS

authors: dockleryxk jaysaikia

repo: dockleryxk/ng-simple-slideshow

license: mit


text:
Calc width

in
SetButtonsPosition()
replace
buttonWidth = buttonWidth * (height / buttonHeight);
with
buttonWidth = Convert.ToInt32(buttonWidth * (double)height / buttonHeight);

You raised a spot that should be taken care of, but your proposed solution has two conversions which does not look good either. Will do more investigation.

authors: gmozhaev lextm

repo: dockpanelsuite/dockpanelsuite


text:
Services UI grab bag

Feature Request
Desired behaviour

[x] Refresh individual service
[x] Sync organization services
[x] Add back plus button
[x] Get rid of shared services
[x] Modal for register services
[x] Add sync next to manage github
[x] Services description version
[x] Change Register service to managed on GitHub
[x] Change refresh button (single service) to sync
[x] Load entry-specific action buttons at same time (Publish, View Public, Refresh, etc)
[x] Hide share with me
[ ] ~Change to GitHub icon for desktop, dropdown for mobile~
[ ] Investigate validation per file
[ ] ~Need a better message for missing version description~
[ ] Weird tooltip when there's no services "Requires source control token" overlaps with the button tooltips

Possibly going to split some of these out
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Fix Versions: Dockstore 1.7
┆Sprint: Seabright Sprint 15 Outrigger
┆Issue Number: DOCK-828
┆Epic: Dockstore  My Services

Sync button is added, but non-functional. However, Charles ticket to hook it up to the UI will have it's own review so I think this can be considered done.
Issues that are checkmarked working on staging API - 1.7.0-beta.1
UI - 2.4.0-beta.1.
Created another ticket for the other two #2707

authors: NatalieEO garyluu

repo: dockstore/dockstore


text:
Better handling for many workflows in a .dockstore.yml

Is your feature request related to a problem? Please describe.
If you have multiple workflows in a .dockstore.yml, the web service's GitHub release endpoint loads all the workflows into memory. This includes a lot of data, we're seeing 261MB responses for the GATK repo, which has ~15 workflows in it.
Needs investigation as to why it's consuming so much memory -- is it just versions, or does it also include source files? Source files should be lazy, but maybe something is fetching them.
Describe the solution you'd like
Brainstorm:

Improve the efficiency

I think we load all versions so we can look for a matching one. Can we search for an existing version directly with HQL? Would we be able to add a new version in Hibernate without having the existing version?
Are we loading the sourcefiles? If so, why, and can it be avoided.

Process each workflow in its own transaction

Programatically start and finish a transaction for each workflow in the .dockstore.yml
This way each workflow can be garbage collected right way, instead of waiting for all 15 workflows to be processed
But how do you handle some of the transactions passing and some failing, especially in notifying the lambda.

The lambda fetches the .dockstore.yml, parses it, and invokes an endpoint for each workflow. I don't really like this, but:

On the minus side, puts .dockstore.yml logic in the lambda.
Lambda will also need a token.
On the plus side, saves a lot of noise hitting the web service, e.g., all the events we get for repos that don't even have a .dockstore.yml

┆Issue is synchronized with this Jira Story
┆Issue Number: DOCK-1730
┆Sprint: Backlog
┆Issue Type: Story

I think we load all versions so we can look for a matching one. Can we search for an existing version directly with HQL? Would we be able to add a new version in Hibernate without having the existing version?

Important and I kinda assumed this was happening (but can easily see how this was missed/regressed)

Are we loading the sourcefiles? If so, why, and can it be avoided.

We do load the sourcefiles because they need to get updated to match what's on github

We do load the sourcefiles because they need to get updated to match what's on github

But in theory only for the version that has been updated/added? I'm trying to understand where 260MB comes from, and was guessing all sourcefiles from all versions are being loaded, which wouldn't seem necessary.

Review: verified that many workflows in .dockstore.yml still works as expected with changes in dev.

authors: GFJHogue NatalieEO coverbeck denis-yuen


text:
Port of docopt to F#

Hello,
I have made a port of docot for F# here!
It is stable and can be used in real world projects, but the API may change a lot until the 1.0 release.
Of all the tests, I chose to remove the ones who tests how the results are returned. Returning null (and using) null is not common in the F# world, so everything returns a value for pattern matching.
Except those two or three, all of them are successful and the test script can be found in Build/Tests/TestCases/TestCases.fs
Can you add me and this project to the organization?
Thanks!

Hey well done! @keleshev  usually does the org thing, I will do it this weekend if he does not pick this up.

@Aksamyt how about a type provider API? Great work!
I'll add the repo to the org tomorrow.

@keleshev yeah that’s my priority, that small start up lag hate is growing on me :stuck_out_tongue:
Thanks! May I close the issue?

@Aksamyt I added you to the docopt organization. I think you can move the repo now. Should we name the repo docopt.fs?

@keleshev All done! I transferred the repo as docopt.fs

authors: Aksamyt keleshev voieducode

repo: docopt/docopt


text:
BasicEntityPersister::count() return type fix

Resolve #6810 by casting return value to integer (2.5.x branch)

@vkurdin thanks for helping us to backport this fix but we do need to have the tests as well. Maybe cherry-picking the original commit(s) and addressing the the conflicts would be a better solution?

@lcobucci no conflicts introduced after cherry-picking the original commit to 2.5 branch. On the other side new functionality was added: EntityRepository::count method. Is that ok to introduce new feature to 2.5 branch?

@vkurdin we shouldn't introduce new features on 2.5 but don't we have any test that ensures that we're returning the correct type on that method (not even an assertSame())?

I've meant tests for BasicEntityPersister#count(). If we don't we should probably do something about that on 2.6 as well

@vkurdin I've found (on v2.6) the test that covers this method and, unfortunately, we are using assertEquals() and not assertSame(). So it's fine to merge this on 2.5 but we should fix BasicEntityPersisterTypeValueSqlTest#testCountEntities() on master (eventually).

@vkurdin 🚢 thanks for your contribution!

authors: lcobucci vkurdin


text:
Functional test to demonstrate that modifications to embedManys do not work as expected if @preUpdate hooks are used

When preUpdate hooks are used, Doctrine ODM does not handle changes to embedMany elements correctly.
The attached functional test only passes when the preUpdate hook is removed.

@blockjon for the record I do want to fix this but I'm going on vacations next week and as usual there's like million things to take care of so I won't promise I'll be the one to fix the bug before October. I may be able to guide somebody though, just ping me on IRC before Monday

@malarzm Not a problem... we have a workaround where there's a very strange coding pattern that helps us avoid this problem..but once you are back I would love to see a fix so we can simply our code. Thank you!

FWIW these two things seem easier than weird patterns (or maybe you're even using one of these :) ).

$doc->embeds->add($embeddedDoc); -> $doc->embeds->add(clone $embeddedDoc);
$doc->embeds = new ArrayCollection(array($doc->embeds->first())); instead of clearing and adding

Both things above are making the test pass however I agree the fail is strange :)

Ah got it, now I mentioned cloning or not calling clear() it becomes kind of obvious: calling clear() schedules all embedded documents for deletion and later they're not picked up by PersistenceBuilder because of their state. IIRC persisting document scheduled for deletion will unschedule it from deletion so probably the same thing can be done for embedded documents - if embedded documents that are scheduled for deletions are found during change set calculation their state needs to be changed.
As for preUpdate exhibiting the bug I believe that it's second change set calculation that makes a difference as it takes place after lifecycle callback is executed. Anyway I'll try to go down the path described before and see if nothing breaks

PR incoming!

Fix has been merged in #1248.

authors: alcaeus blockjon malarzm

repo: doctrine/mongodb-odm


text:
docz dev 和 docz build 有不同的故事

Bug Report
Describe the bug
我的svg和less在docz dev时是没有问题的，但是在docz build托管至github pages时，不好用了。使用了'gatsby-plugin-less'，'gatsby -plugin-svg-sprite'。
** 预期 docz dev时 **

** 实际现象 docz build 后托管github pages时 **

这让我有点失去对docz的使用信心。不知道是什么差异带来了这个问题。

问题已经解决，是package中sideEffects带来的困扰

repo: doczjs/docz

license: MIT


text:
Cowboy hat sprite

Added sprite for #107 Create Sprite for Cowboy Hat

Hi @Laxaor! Very nice sprite, thanks for contributing. :smiley:

authors: Laxaor doficia

repo: doficia/project-cordon-sprites


text:
Request feature - Externalize download interval variable

Hello there,
I'd like to request a feature : I saw in your code that you're using a variable to store the download interval, which is used to reduce the load on patreon server. I'm not sure this one is used (or I'm bad enough with JS to not notice it), but do you think you could make it available to changes through the preferences tab in extensions page ?
The point is that, currently, your extension is perfectly suitable to a normal usage (pictures, music for example). Problem is that I also use it to download heavier stuff, like .psd which are around 100mo+. It messes up the stuff, since the download doesn't finishes in time to get added to the database. It causes me various problem : either the file is download again and stored into the Download folder specified by the browser and not the extension, or next files get tagged as "_unknwon" even if the first one of the post was found. That's the two main behaviour that I saw. Sometimes I got both because why not.
P.S. : Thanks a bunch for this extension, honestly it helps A LOT !

Hey there! You were right, the variable was never used. I've changed that, and with the new version 1.13 that should roll out via AMO very soon, you'll now find a download interval configuration in the setting tab. Let me know if it works as intended. Cheers!

Hey there! You were right, the variable was never used. I've changed that, and with the new version 1.13 that should roll out via AMO very soon, you'll now find a download interval configuration in the setting tab. Let me know if it works as intended. Cheers!

Hello there !
Thanks a lot, it indeed work very well ! :) Sadly, that didn't fixed my issue... I don't really get why, so I'll send you a mail with logs in a few minutes. I'll close this issue since the feature is implemented, don't hesitate to tell me if you want me to open a new one for the mail I'm sending you.

Hello there !
Thanks a lot, it indeed work very well ! :) Sadly, that didn't fixed my issue... I don't really get why, so I'll send you a mail with logs in a few minutes. I'll close this issue since the feature is implemented, don't hesitate to tell me if you want me to open a new one for the mail I'm sending you.

repo: dogpixels/patreon-helper


text:
Add custom StreamProcessorStateDiscriminatorConvetion for AbstractStreamProcessorState serializing

┆Issue is synchronized with this Asana task

Tested with the new stuff from 5.0.0, seems to be working fine. Open for review.

repo: dolittle-runtime/Runtime


text:
[auto-bump] dependency by max-hoffman

:coffee: An Automated Dependency Version Bump PR :crown:
Initial Changes
The initial changes contained in this PR were produced by go geting the dependency.
$ cd ./go
$ go get github.com/dolthub/<dependency>/go@<commit>
$ go mod tidy

Before Merging
This PR must have passing CI and a review before merging.
After Merging
An automatic PR will be opened against the LD repo that bumps the bounties version there.

This PR has been superseded by https://github.com/dolthub/bounties/pull/1210

repo: dolthub/bounties


text:
Duration is not changing

let spinner = Spinner(.dots, message, format: "{S} {T} ⏱ {D}")
spinner.start()

//example of command more then 1s:
shell.run("bundle exec pod install")
spinner.stop()

//Output:
✔ 🫛 Pods install ⏱ 0s

I checked your code and it looks correct, you calculate the value between the start and the current time each time. However, the value does not change
func render() {
        var spinner = self.format.replacingOccurrences(of: "{S}", with: self.frame()).replacingOccurrences(of: "{T}", with: self.message)
        if let timestamp = self.timestamp {
            let duration = Now() - timestamp
            spinner = spinner.replacingOccurrences(of: "{D}", with: duration.timeString)
        }
        stream.write(string: "\r", terminator: "")
        stream.write(string: spinner, terminator: "")
    }

Thank you for good project!

@SeRG1k17 thanks for reaching out. I will take a look into this ASAP and get back to you.

Hey @SeRG1k17 I was not able to replicate the issue you are facing (please see: https://github.com/dominicegginton/spinner/blob/duration-debug/Sources/DebugDuration/main.swift where I have created an example to debug)
import Spinner
import Foundation

@discardableResult
func shell(_ args: String...) -> Int32 {
    let task = Process()
    task.launchPath = "/usr/bin/env"
    task.arguments = args
    task.launch()
    task.waitUntilExit()
    return task.terminationStatus
}

let message = "duration debugging - running sleep cmd"

let spinner = Spinner(.dots, message, format: "{S} {T} ⏱ {D}")
spinner.start()
shell("sleep", "10") // do work
spinner.stop()

Running my example I got the expected result (including duration updates as time progresses):

Please can you provide more information about the environment you are building on and the call to the function shell.run provided example? This may give me more ideas on what could be the problem here.

I managed to get a time greater than 0 seconds, this happens when the command hangs and works for a very long time. It seems more than 1 minute, same on CI. I will try create a sample soon

repo: dominicegginton/spinner


text:
Go-import-add does not show packages from "./vendor"

Hi,
I'm facing an issue when trying to import a package. The list of suggested packages does not show packages exclusively present in the vendor folder (and not the $GOPATH). The issue is resolved when adding the package to the $GOPATH using go get.
Flycheck does not report an issue when I manually key in the package so I guess that is working fine. However, autocomplete does not work for such packages either and requires the workaround using go get mentioned earlier.
Thanks for this amazing integration and any help with this issue!
I'll gladly provide more information if needed.
Cheers!

I think that #264 may fix this issue.

@blatter2016 You can set go-packages-function to go-packages-go-list (but it should be set by default if you use latest go-mode). But there is few problems - it will not strip vendor prefix, and it may work too slow (up to ~10sec on my machine). So I wrote custom go-packages-function here. It will find and cache packages asynchronously including vendors of your project. It works only on startup, so if you need to refresh packages list you can just M-x custom/go-refresh-packages.

authors: blatter2016 buzztaiki zzell


text:
Cannot npm install

Getting a cannon issue:
$ npm install --save aframe-extras
npm WARN peerDependencies The peer dependency cannon@github:donmccurdy/cannon.js       #v0.6.2-dev1 included from three-to-cannon will no
npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency
npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly.
npm ERR! install but already installed versions [ '0.6.2' ]
npm ERR! node v4.4.2
npm ERR! npm  v2.15.0
npm ERR! code EPEERINVALID
npm ERR! peerinvalid The package cannon@0.6.2 does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer three-to-cannon@1.1.1 wants cannon@github:donmccurdy/c       annon.js#v0.6.2-dev1
Removed personal data from the output.

Hm, do you mind trying this with an updated version of npm?
npm update -g npm
npm install

If you need to stay on an older version of npm, you can later revert that with:
npm install -g npm@latest-2

No problem.
Updating npm didn't do any difference, but updating node to newest stable did :) 👍

authors: Rosefalk donmccurdy

repo: donmccurdy/aframe-extras


text:
PCM mono audio passthrough?

Hi,
This is more of a question than a bug, but I'm noticing when I'm transcoding my Criterion blu-ray rips, the older movies w/ PCM mono audio, it doesn't pass through the original audio but encodes it with libaac.   Is this by design or does other_transcoding or ffmpeg doesn't recognize PCM as a pass-through-able format and gamely tries to convert it to AAC?
(also, how good is libaac now vs. the apple encoders?)
Thanks,
Tyler

@tylercheung No, that's by design. PCM audio streams are uncompressed and often huge. In fact, they can be higher in bitrate than the transcoded video, depending on which encoder and ratecontrol method you choose. So, other-transcode, by default, will convert these streams to AAC format for mono and stereo and AC-3 for surround. It's always worked that way.
Of course, you can always add --main-audio 1=original to your options and pass PCM through directly. But I don't recommend it because that would really be missing the point of making a smaller, more portable version of your media.
I hope that answers your question.

BTW, libacc is terrible and no longer used by ffmpeg. Instead, ffmpeg uses a newer and better AAC encoder by default. It's not as good as the Apple encoder because, really, nothing is. But it's perfectly fine for movies. I use it all the time.

I'm going to assume that I answered this question and close this for now.

Yes - apologies for the delay in reply, but this does answer my question - thank you very much!

authors: donmelton tylercheung


text:
Loud short noise at the beginning of recorded audio

Version of react-native-audio-recorder-player
2.4.3
Platforms you faced the error (IOS or Android or both?)
iOS
Expected behavior
Clear sound, as on Android
Actual behavior
Loud short noise at the beginning of recorded audio
Steps to reprodue the behabior
Everything as in example but using it together with react-native-camera (in fact mounting audio after unmounting camera)

Example of noise: https://www.dropbox.com/s/mn4qw0fyeezr8fb/1575970204688-55696.m4a?dl=0

please share your code im in lot of trouble


text:
Modules support

This is a WIP PR implementing ECMAScript Modules (ESM) in goja.
The PR does add every ESM feature as of ES2022 including:

basic import/export syntax.
module namespace import * as ns from "somewhere".
dynamic import.
async module evaluation, even though the source text module do not support top level await. This definitely needs more testing as it was added fairly recently and required ... a bit of refactoring.

The WIP part of this PR comes from the fact that there are many open implementation specifics that I am not certain about and at least for some of them I would need your input, @dop251.
(For not @dop251, while I will appreciate any input, if you just want to try it out - this might be a bit hard as there is no documentation. Also, as mentioned below a lot of the APIs will change. But if you really want look at modules_integration_test.go as that likely is the best place for a small(ish) but fully working example)
Why open an unfinished PR
I have worked on this on and off since I guess December, but mostly in the last 3 months. Unforunately while I did manage to implement most stuff I just kept getting more and more questions that likely I should've asked earlier. Also, I am getting more and more other work that also needs to get done. Because of that I decided to try to get some feedback on the current implementation in hopes that will make things easier for both of us.
I will try to ask most of the questions inline/incode, this hopefully will help with threading, but we can also move any discussion in another place if you want to. For some of the questions I have - I also have ideas, which I will probably go with when I have the time even if you haven't come back to me. Also, all my links will be to my branch, because links to code in big PRs just plain don't work, and you would likely want to open them locally either way.
Again I will continue working on this, but hopefully with some help the time it takes me will be smaller. It likely also will make this easier for you to review in the end ;)
Tthere are a bunch of:

commented fmt.Print* lines that will be removed in any final PR.
TODOs coments which will also be removed as I go through them.
big functions that will likely be broken in smaller ones.

You can probably ignore those unless you want something to stay or want to given some specific feedback there.
I have tried to not change anything in goja that I don't need, but I still needed to touch stuff which aren't directly about modules. Hopefully all of are fine.
Really sorry for the formatting changes in some places. I have tried to bring them to a minimal as to not just move code around. I should've probably disabled gofumpt for this entire project and that would've helped more 🤷♂. I can probably try to remove them one final time after everything else is done.
This whole PR should be squashed in the end. Some commits are kind of useful if you need to figure out what I have tried, but most of it is likely very outdated and will definitely not be useful once we are done with this feature.
I guess first:
Are you interested in goja having ESM support in general? And do you see any fundamental issues with the approach I have taken and have not asked questions for?
It's quite a big change, I will fully understand if you don't want it or, do not have time to code review it and help me right now or until I am actually of the opinion I am done.
Background on why I am working on this and a particular problem I still need to fix in k6
I specifically wanted to work on this as in k6 we do have this, I guess unfortunate, requirement that import "commonjsModule" needs to work as well as require("ESMmodule"). Cycles of both of them aren't that necessary to be supported (although I guess it will be nice if I can make them work 🤷♂).
Due to k6 currently using babel internally to transpile ESM to CommonJS, users have been using both and because transpiling takes time we have historically made helper modules as CommonJS :(. So this all leads to the fact that some interoperability is heavily required.
Luckily I haven't really done anything to the code design to make it possible 🤷♂it just kind of works on the most basic level as shown in the k6 PoC PR
That k6 PR apart from lacking a ton of tests, mostly to test cycles and interoperability, has only 2 known bugs/problems - so probably a lot more 😢.
Both open and require  should be relative to the script/module that is the current "root" of execution, instead they are currently (in that PR) relative to the file that is the main script/module - the argument to k6 run this/file/here.js.
This is one of those really hard to explain with just words problems. But I basically need activeScriptOrModule, but instead of returning the module we are currently "in" (as in the code/text place), I need the one that is the root of the execution.
And yes I (now) know that require is supposed to be relative to the file it's written in just like import()... but that is literally not how it has been since k6 was made and even if we change that ... open still exists. I have opened an issue to figure out if k6 would not want to change this.
You do currently do this in goja_nodejs here, but I am not sure this works with source maps (it seems to, I guess I am wrong where the "rename" happens 🤷♂) but in order to get the "root" module/script I will need to go through the whole stack ... which might be big :(. I kind of feel like that is an okay thing for goja to provide. What do you think?
(Note: currently k6 can know which the currently executing script file as it is the only thing that is executing stuff, once goja starts evaluating cyclic modules this will no longer work)
Edit: I just posted all of the comments inline and noticed, while copying the messages I had prepared, that the order of the code in the PR as always does not in any way reflect how the code actually flows :facepalm:
I would recommend looking at something like modules_integration_test.go to see how the code is used and then following the code from there. I would argue also that the most important comments and questions are in modules.go and compiler.go.
Also thanks again for working on goja :bow:

yummmy!!!

I would definitely like to have the modules functionality (because it's part of the specs), however considering modules are all asynchronous in the current version of the specs, the logical order of implementation should be:

Generators (which includes execution context, i.e. ability to save and restore the state of execution, which in turn will require changing the exception handling).
async/await.
Modules.

I am planning to do the generators next (but as per usual, no ETA), and eventually the rest, although the remaining 2 items are lower priority. If you (or anyone else) would like to pick them up afterwards, that would be most welcome.
As for the implementation, I only had a chance to have a quick look, one thing that strikes me is the indirection mechanism, I think it should be given some more thought. Not only it looks a bit hacky, I don't think it would work with dynamic resolution (i.e. eval("importedName"). But to stress, without 1 and 2 any implementation would be premature and would require extra work afterwards.

Hi, first thanks for the response :bow:

I would definitely like to have the modules function

Great!!!

But to stress, without 1 and 2 any implementation would be premature and would require extra work afterwards.

I would like to push back on this. In practice while the current implementation let them be asynchronous that isn't what will be the case most of the time and IMO top-level-await support can be added when async/await is added.
But ESM definitely touches a lot of stuff and each feature addfed makes this even bigger. For example when you added classes (thanks again :bow: ) I was more at dynamic imports and needed to merge the classes. I am happy to say that it was mostly just merging.
It will definitely be more work when generator and async/await are added, but I would argue probably very little compared to the rest of the things needed in that.
That is to say that I am fairly certain no big changes will be needed to the module code apart from in the particular places that this feature interact:

parsing the extra modules stuff and moving it through the code
some changes to how the execution of the source text module happens so it can use top level await.

But the actual support for tla from the modules perspective is there ... albeit untested and that definitely needs to be done.
And again the whole PR needs a lot more tests and if we do the refactoring of the types and names in modules.go likely quite a lot more changes as well.
I also have problems with teh current asynchronous nature of the evaluation as it makes us use Promises, which in itself is nice, but that means that we need to cast types everywhere where in reality there should be only 2 possibilities.

As for the implementation, I only had a chance to have a quick look, one thing that strikes me is the indirection mechanism, I think it should be given some more thought. Not only it looks a bit hacky, I don't think it would work with dynamic resolution (i.e. eval("importedName").

Unfortunately you are right :facepalm: and tc39 tests again don't cover this or are disabled for some other missing feature :scream: .
Also unfortunately that means that I will now need to figure out how eval resolves bindings, which I think I did have some idea at some point :(.
Any suggestion on this will be nice though
For the record I do have a WIP (not a PoC) implemetnation of generators - I am at the "compile generators" part so ... likely many free afternoons away from it beign a PoC :(.
And as I have said we are intersetd in async/await and will work on it if possible (I just also know that it is dependant on generators), but also modules are the last thing we use babel for in k6 atm. And unfortunately with our current version of babel(which we really don't want to go through updating it for many different reasons) means that it supports syntax from 5+ years ago :(. Also this is kind of big change on our side as well.
But if you are absolutely possitive we need generators and async/await first I guess I will argue for pivoting some more resources (me) to implemeting those.

@mstoykov I'm always quite excited when you make changes here because you've added a few great things. I have a fair bit of totally unrelated dev experience, and yet when I've thought about contributing to goja, I never quite get past the learning and absorbing hump into starting something.
You talked a bit about files and resolving paths etc. However, I'd be very very happy if this sort of thing was solved with something like the fs.FS interface. You could have a default set to nothing (security?) or to something standard, but your project would be able to pick something else. Someone out there might decide that they instead want to write their own implementation of FS or use S3 that lazy loads into memory for all I know. Someone might want everything embedded into the binary. All of this is easy to accomplish with the FS interface. I suspect you would get far more flexibility while also achiving a cleaner feeling result at the same time.

https://benjamincongdon.me/blog/2021/01/21/A-Tour-of-Go-116s-iofs-package/
https://pkg.go.dev/io/fs@master#FS

I would actually be very slightly sad to see goja get proper module support without the ability to use embed, and at the same time, I also assume this wouldn't be the default or even a very high priority, but for some it would be huge, so I very much hope fs.FS is the answer that supports 99% of all use cases without any real downsides.

hi, @mstoykov.
I look forward to more exciting features in your k6!
(sync)generator, async is now available. can you restart the esmodule?

@arukiidou there are plans for this to be worked on in the following weeks.

@mstoykov Since you might revisit this, I wanted to revisit what I mentioned regarding using https://pkg.go.dev/io/fs#FS for configuring the module loader. When you said that you didn't think a specific implementation could be in goja itself, I kept wanting to circle back to point out that io.FS is an interface, not an implementation. If you accept the io.FS interface (io package, with just one method required: Open(name string) (File, error)), then one could use embed, a directory (os.DirFS which might be what you thought I meant originally), S3, a url, or anything else you want since it's a standard way to do this and there are options already written in or out of the standard library already. It would be maximally flexible. You could make an implementation in another repo that mimics webpack or systemjs. You could use something from the standard library out of box, or you could use myriad other options even if they don't mimic something from the node or web world.

Just wanted to ping you @dop251.
I have removed the not-quite-yield hack I had and have made eval working as far as I can see.
Also top-level-await is also working.
AFAIK any modules features currently is working or .,.. I don't know about it :sweat_smile:.
The code definitely needs way more work. But I want to touch bases on what direction the current base should be moved into.
On my "short" TODO list are:

realign the current implementation more with the current specification. While the code works, the specification changed twice over the time this has been worked on, so definitely some things are now called differently or are slightly differently explained. One of those changes helped me a lot as it specified more clearly how a thing should work, I expect other such will be also helpful. I just haven't had time to go through the code from one end to the other to check everything.
I do think the current exportIndirect and co. are not great - they were what I managed to do over a year ago, understanding way less than I do now. Unfortunately even now I would argue I do not have a much better way to do it that probably won't be even more performance degrading. Arguably for only source modules we can directly reference the stash of another module. Any ideas or pointers will be great.
The API that is exposed to the end user evolved ... uh ... naturally aka it is pretty crappy. Forget that it doesn't have any documentation (which also is a problem) it is way worse then before as it now have even more promises everywhere. Considerable amount of the work was to try to keep the error path to always resolve with an actual error instead of maybe an error maybe something else. The plan here is that I probably should be wrapping more of an object with function fields which will be way easier to work with then a bunch of interfaces. But more importantly won't require the user to implement multiple interfaces where most of the methods return false/nil or something similar.
Every inline TODO

Any feedback is welcome, I am writing this now, as I will be away for a bit leaving you with some time and also managed to get everything in the working but pretty ugly state.
There is a newer k6 PoC PR that hacks around some stuff and can be used as an example (on top of the integration tests) of how this should be used until I write documentation.
p.s. to everybody else - sorry for not coming back sooner, but making this work seemed more important than discussing the final API. Hopefully after a few rounds with @dop251 we will get to your points as well.

Thanks for working on this. Unfortunately I'm rather time constrained at the moment, and it's a big PR to review, but I'll get to it as soon as I can. It would be nice to close this final gap so that ES6 is fully supported.

Its been a couple months now, what's the status of this?

I am also wondering about when this PR will merge

After some internal discussion within the k6 team we have decided upon forking goja.
This is in part to get this PR going, but also as the JS engine is integral part of k6, us being able to make changes to it in a timely manner is paramount.
Some of those changes though might not be beneficial to goja or not stable enough.
As such this PR is now merged in our fork Sobek and due to the potential of us changing the API, I have removed backwards compatibility on the API from the README. It is very likely in the future the API will be completely redone, hopefully in a way that is easier on the user.
The k6 team does intend to keep Sobek and goja as close as possible code wise and to this end we will be back porting any future changes to Sobek and merging changes from goja in Sobek. Including this PR or at least its functionality when it is considered ready. Or if it ends up being included in goja in another way we will try to integrate those changes in Sobek.
Thank you for all the work done on this project @dop251 🙇.

authors: PaluMacil arukiidou cdle dop251 gabereiser mstoykov zakiRefai


text:
[Snyk] Upgrade @types/react from 18.0.15 to 18.3.12

Snyk has created this PR to upgrade @types/react from 18.0.15 to 18.3.12.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 116 versions ahead of your current version.

The recommended version was released on a month ago.

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:

🧐 View latest project report
📜 Customise PR templates
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

:tada: Snyk checks have passed. No issues have been found so far.
:white_check_mark: security/snyk check is complete. No issues have been found. (View Details)

repo: doperiddle/web-examples


text:
[typescript-graphql-request] importOperationTypesFrom does nothing

Describe the bug
The docs for typescript-graphql-request describe that importOperationTypesFrom could be used to import the operations from another file. But whatever I do, it seems to do nothing.
To Reproduce
Codesandbox: https://codesandbox.io/s/boring-paper-rsces?file=/codegen.yml
Additional context
I made it work with this snipped. Bu I think importOperationTypesFrom should do that for me.

plugins:
  - add:
      content: "import * as Types from './types';"
  - typescript-graphql-request
config:
  typesPrefix: Types.

Thanks @lanwin . The importOperationTypesFrom isn't currently supported on all plugins :( PRs are welcome!

authors: dotansimha lanwin

repo: dotansimha/graphql-code-generator


text:
Plugin Level configuration not validating in vscode

Describe the bug
When adding configuration per plugin, the schema is considered invalid

To Reproduce
Steps to reproduce the behavior:
Code sandbox doesn't seem to validate the schema, so no code sandbox applies

My GraphQL schema:

Not applicable

My GraphQL operations:

Not applicable

My codegen.yml config file:

overwrite: true
schema: "src/core/graphql/schema.graphql"
# These are used to automatically generate the various React hooks we use from documents
documents:
  - "src/**/*.graphql"
hooks:
  afterOneFileWrite:
    - prettier --write

generates:
  src/core/graphql/schema.ts:
    - typescript:
        declarationKind: "interface"
        enumsAsTypes: true
        defaultScalarType: unknown
        skipTypename: true
    - "typescript-operations":
        declarationKind: "interface"
        avoidOptionals: true
        defaultScalarType: unknown

Expected behavior
I would expect to be able to get autocomplete / validation in vscode as suggested in the documentation when inputting a valid config. The CLI command generates the correct output, so the config is technically correct, it's just the YAML schema that doesn't seem to support plugin level configuration
Environment:

OS: MacOS
@graphql-codegen/...:

"@graphql-codegen/cli": "~1.21.7",
"@graphql-codegen/typescript": "~1.23.0",
"@graphql-codegen/typescript-operations": "~1.18.4",

NodeJS: v14.17.0

Additional context
Using RedHat YAML plugin as suggested by docs. v0.21.1 which is the latest version at the time of this writing.

@dotansimha I'm willing to pick this up to get it fixed if you / someone can point me in the general direction of what I would need to change

@dotansimha I'm willing to pick this up to get it fixed if you / someone can point me in the general direction of what I would need to change

This might be tricky. We are generating a JSON-Schema (schema.json) file based on the TypeScript signatures, and then we have a script that knows how to build the entire tree. I think there might be a bug there.
The code for this script is here: https://github.com/dotansimha/graphql-code-generator/tree/master/packages/utils/config-schema/src

Note that root-level config isn't correct in the JSON schema either, there is no autocompletion and validation fails.

Fixed!

authors: aaronadamsCA dotansimha willsoto


text:
[client-preset] React-query example... Isn't strongly typed. data is any etc.

    > > React-query example... Isn't strongly typed. `data` is `any` etc.

Hi @Faithfinder,
Could you provide more context about which example you are referring to? The client-preset provides typed GraphQL operations when React Query is used in combination with a supported GraphQL client (ex: graphql-request@^5) or when the fetcher is properly typed (as documented in our guide).

Just checking out an example you've supplied: https://github.com/dotansimha/graphql-code-generator/tree/v3-preset-front-end/examples/front-end/react/tanstack-react-query
Using twoslash here to demostrate that data is any, and on request to demonstrate that yarn install has been run and types are in place, generally.

Originally posted by @Faithfinder in https://github.com/dotansimha/graphql-code-generator/issues/8296#issuecomment-1285557290

As I keep repeating, it's your package.json. I literally just checked out the example from the repo. Checked out, as in git clone the repo and yarn in the directory of the example.
https://github.com/dotansimha/graphql-code-generator/blob/master/examples/front-end/react/tanstack-react-query/package.json
One of the problems is that graphql itself is not installed. If I install it, then some types for data appear, but not all of them. If I try to look at data?.allFilms?.edges[0]?.node, it only has __typename, no typings from fragment.

You are right, the graphql dev dependency is missing; I'll add it.
The typing of fragments is only accessible from the <Film> component; this is because of the Fragment Masking, as explained in our guide.
The current behavior of your local setup is working as expected.

authors: Faithfinder charlypoly


text:
not stable

after 3-4 disconnect and reconnection not connect again .
and eating cpu.

not accept new connection after 5 minute of running...

i write this script seems work good
#!/bin/bash while true                        #begin infinite loop (you'll have to manually kill) do   mtproxy -s 'ahmad' &                   #execute myprogram and background   PID=$!                          #get PID of myprogram   sleep 120                      #sleep 30 minutes (30m might work as parameter)   kill -9 $PID                    #kill myprogram done

@amin1softco work in progress, stable version will be published after Telegram releases MTProxy feature.

repo: dotcypress/mtproxy


text:
fatal: Could not read from remote repository.

git clone git@github.com:dotcypress/ula.git
Cloning into 'ula'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Hi, I encountered this error while following your guidelines, could you fix it please?

Hey @galacticfr
You can use HTTPS endpoint for cloning public repos: git clone https://github.com/dotcypress/ula.git

authors: dotcypress galacticfr

repo: dotcypress/ula


text:
K8s Dashboard not accessible

According to this instruction
the dashboard should be accessible at
http://localhost:port/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
In my case it is not accessible at all.
`kubectl proxy port 8888
`http://localhost:8888/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
triggers

Error: 'tls: oversized record received with length 20527'
Trying to reach: 'https://10.244.0.6:9090/'

and

http: TLS handshake error from :53950: EOF

Has anyone experienced this issue?

There are at least two bugs in different versions of k8s that result in the dashboard not accessible using http://localhost:8001/ui (which just performs a redirection)
One is solved appending a / at the end of the url once redirection is done (afaik happened in k8s 1.7.something)
Another is solved by changing the url section https:kubernetes-dashboard by http:kubernetes-dashboard (remove the s). Afaik this bug was in k8s 1.9.something

authors: eiximenis lmiroslaw

repo: dotnet-architecture/eShopModernizing