debug go version for unit test

Signed-off-by: anandrkskd<EMAIL_ADDRESS>What type of PR is this?

Uncomment only one  /kind line, and delete the rest.
For example, > /kind bug would simply become: /kind bug

/kind api-change
/kind bug
/kind cleanup
/kind deprecation
/kind design
/kind failing-test
/kind feature
/kind flake
/kind code-refactoring
Documentation changes: CI will automatically skip test runs if it is a doc related change.
/kind documentation

What does this PR do / why we need it:
Which issue(s) this PR fixes:
Fixes #?
PR acceptance criteria:

[ ] Unit test

[ ] Integration test

[ ] Documentation

[ ] Update changelog

[ ] I have read the test guidelines

How to test changes / Special notes to the reviewer:

From ci/prow/unit log it seems it dosen't use the dockerfile which is in this branch( the changed Dockerfile), so we are not able test the changes here. I have used it in the local, and it was working.
So should we merge this to check if its working or not?
Cc_: @mohammedzee1000 , @prietyc123

@anandrkskd It seems unit tests are running fine now. I have observed it on pr https://github.com/openshift/odo/pull/4754

@anandrkskd It seems unit tests are running fine now. I have observed it on pr #4754

@prietyc123 those PRs are not running rpm tests under unit test, so they will pass. but this PR is running build test

Is the PR still relevant?

Is the PR still relevant?
yes Dharmit, as we are not running rpm test on our PR, previously it was run on unit test but when we updated the golang version it was causing failure.
This PR should fix it.

@prietyc123  here is the logs  that you I inside the containers with these changes

[root@1f7620d555b7 odo]#  yum -y install make wget gcc git httpd-tools golang
...
Installed:
  golang.x86_64 0:1.15.5-1.el7                                                                       httpd-tools.x86_64 0:2.4.6-97.el7.centos
Dependency Installed:
apr.x86_64 0:1.4.8-7.el7    apr-util.x86_64 0:1.5.2-6.el7  golang-bin.x86_64 0:1.15.5-1.el7   golang-src.noarch 0:1.15.5-1.el7        libmodman.x86_64 0:2.0.1-8.el7        libproxy.x86_64 0:0.4.11-11.el7
neon.x86_64 0:0.30.0-4.el7  pakchois.x86_64 0:0.4-10.el7   subversion.x86_64 0:1.7.14-16.el7  subversion-libs.x86_64 0:1.7.14-16.el7  systemd-sysv.x86_64 0:219-78.el7_9.3
Dependency Updated:
systemd.x86_64 0:219-78.el7_9.3                                   systemd-devel.x86_64 0:219-78.el7_9.3                                   systemd-libs.x86_64 0:219-78.el7_9.3
Complete!
[root@1f7620d555b7 origin]# ￼
bash: ￼: command not found
[root@1f7620d555b7 origin]# git clone github.com/openshift/odo
fatal: repository 'github.com/openshift/odo' does not exist
[root@1f7620d555b7 origin]# git clone https://github.com/openshift/odo
Cloning into 'odo'...
remote: Enumerating objects: 108692, done.
remote: Counting objects: 100% (1046/1046), done.
remote: Compressing objects: 100% (684/684), done.
remote: Total 108692 (delta 440), reused 789 (delta 323), pack-reused 107646
Receiving objects: 100% (108692/108692), 142.73 MiB | 5.02 MiB/s, done.
Resolving deltas: 100% (56276/56276), done.
[root@1f7620d555b7 origin]# cd odo
[root@1f7620d555b7 odo]# ls
appveyor.yml  Changelog.md  Dockerfile.rhel  go.mod  LICENSE   openshift-ci  pkg          README.adoc  scripts                   tests            vendor
build         cmd           docs             go.sum  Makefile  OWNERS        plugin.yaml  rpms         sonar-project.properties  USAGE_DATA.adoc  website
[root@1f7620d555b7 odo]# export GOROOT="/usr/lib/golang"
[root@1f7620d555b7 odo]# export GOPROXY="https://proxy.golang.org,direct"
[root@1f7620d555b7 odo]# export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/go/bin:/usr/lib/golang
[root@1f7620d555b7 odo]# ./\scripts/rpm-x86_64-test.sh
Preping rpm
Reading ODO_VERSION, ODO_RELEASE and GIT_COMMIT env, if they are set
Printing envs for verification
ODO_VERSION=2.2.4
ODO_RELEASE=1
GIT_COMMIT=aa90c53
ODO_RPM_VERSION=2.2.4
GOLANG_VERSION=1.15
GOLANG_VERSION_NODO=115
Making release for openshift-odo-2.2.4-1, git commit aa90c53
Cleaning up old content
Configuring output directory .rpmbuild
Generating spec file .rpmbuild/SPECS/openshift-odo.spec
Generating tarball .rpmbuild/SOURCES/openshift-odo-2.2.4-1.tar.gz
/go/src/github.com/openshift/origin/odo/.rpmbuild/SOURCES /go/src/github.com/openshift/origin/odo
/go/src/github.com/openshift/origin/odo/.rpmbuild/SOURCES/openshift-odo-2.2.4-1 /go/src/github.com/openshift/origin/odo/.rpmbuild/SOURCES /go/src/github.com/openshift/origin/odo
/go/src/github.com/openshift/origin/odo/.rpmbuild/SOURCES /go/src/github.com/openshift/origin/odo
/go/src/github.com/openshift/origin/odo
Finalizing...
Generated content in /go/src/github.com/openshift/origin/odo/dist/rpmbuild
Building rpm
Building locally
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.GVUF7g

umask 022
cd /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD
cd /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD
rm -rf openshift-odo-2.2.4-1
/usr/bin/gzip -dc /go/src/github.com/openshift/origin/odo/dist/rpmbuild/SOURCES/openshift-odo-2.2.4-1.tar.gz
/usr/bin/tar -xf -
STATUS=0
'[' 0 -ne 0 ']'
cd openshift-odo-2.2.4-1
/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.bJpfLT
umask 022
cd /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD
cd openshift-odo-2.2.4-1
export GITCOMMIT=aa90c53
GITCOMMIT=aa90c53
mkdir -p /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD/gocode/src/github.com/openshift
++ pwd
ln -s /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD/openshift-odo-2.2.4-1 /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD/gocode/src/github.com/openshift/odo
export GOPATH=/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD/gocode
GOPATH=/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD/gocode
cd /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD/gocode/src/github.com/openshift/odo
go mod edit -go=1.15
GOFLAGS=-mod=vendor
make test
go test  -race github.com/openshift/odo/cmd/cli-doc github.com/openshift/odo/cmd/odo github.com/openshift/odo/pkg/application github.com/openshift/odo/pkg/application/labels github.com/openshift/odo/pkg/auth github.com/openshift/odo/pkg/catalog github.com/openshift/odo/pkg/component github.com/openshift/odo/pkg/component/labels github.com/openshift/odo/pkg/config github.com/openshift/odo/pkg/debug github.com/openshift/odo/pkg/devfile github.com/openshift/odo/pkg/devfile/adapters github.com/openshift/odo/pkg/devfile/adapters/common github.com/openshift/odo/pkg/devfile/adapters/kubernetes github.com/openshift/odo/pkg/devfile/adapters/kubernetes/component github.com/openshift/odo/pkg/devfile/adapters/kubernetes/storage github.com/openshift/odo/pkg/devfile/adapters/kubernetes/utils github.com/openshift/odo/pkg/devfile/convert github.com/openshift/odo/pkg/devfile/validate github.com/openshift/odo/pkg/envinfo github.com/openshift/odo/pkg/kclient github.com/openshift/odo/pkg/kclient/fake github.com/openshift/odo/pkg/localConfigProvider github.com/openshift/odo/pkg/log github.com/openshift/odo/pkg/log/fidget github.com/openshift/odo/pkg/machineoutput github.com/openshift/odo/pkg/notify github.com/openshift/odo/pkg/occlient github.com/openshift/odo/pkg/odo/cli github.com/openshift/odo/pkg/odo/cli/application github.com/openshift/odo/pkg/odo/cli/catalog github.com/openshift/odo/pkg/odo/cli/catalog/describe github.com/openshift/odo/pkg/odo/cli/catalog/list github.com/openshift/odo/pkg/odo/cli/catalog/search github.com/openshift/odo/pkg/odo/cli/catalog/util github.com/openshift/odo/pkg/odo/cli/component github.com/openshift/odo/pkg/odo/cli/component/ui github.com/openshift/odo/pkg/odo/cli/config github.com/openshift/odo/pkg/odo/cli/debug github.com/openshift/odo/pkg/odo/cli/env github.com/openshift/odo/pkg/odo/cli/login github.com/openshift/odo/pkg/odo/cli/logout github.com/openshift/odo/pkg/odo/cli/plugins github.com/openshift/odo/pkg/odo/cli/preference github.com/openshift/odo/pkg/odo/cli/project github.com/openshift/odo/pkg/odo/cli/registry github.com/openshift/odo/pkg/odo/cli/registry/util github.com/openshift/odo/pkg/odo/cli/service github.com/openshift/odo/pkg/odo/cli/service/ui github.com/openshift/odo/pkg/odo/cli/storage github.com/openshift/odo/pkg/odo/cli/telemetry github.com/openshift/odo/pkg/odo/cli/ui github.com/openshift/odo/pkg/odo/cli/url github.com/openshift/odo/pkg/odo/cli/utils github.com/openshift/odo/pkg/odo/cli/version github.com/openshift/odo/pkg/odo/genericclioptions github.com/openshift/odo/pkg/odo/util github.com/openshift/odo/pkg/odo/util/completion github.com/openshift/odo/pkg/odo/util/experimental github.com/openshift/odo/pkg/odo/util/validation github.com/openshift/odo/pkg/odogenerator github.com/openshift/odo/pkg/preference github.com/openshift/odo/pkg/project github.com/openshift/odo/pkg/secret github.com/openshift/odo/pkg/segment github.com/openshift/odo/pkg/segment/context github.com/openshift/odo/pkg/service github.com/openshift/odo/pkg/storage github.com/openshift/odo/pkg/storage/labels github.com/openshift/odo/pkg/sync github.com/openshift/odo/pkg/sync/mock github.com/openshift/odo/pkg/testingutil github.com/openshift/odo/pkg/testingutil/filesystem github.com/openshift/odo/pkg/unions github.com/openshift/odo/pkg/url github.com/openshift/odo/pkg/url/labels github.com/openshift/odo/pkg/util github.com/openshift/odo/pkg/version github.com/openshift/odo/pkg/watch
?   	github.com/openshift/odo/cmd/cli-doc	[no test files]
?   	github.com/openshift/odo/cmd/odo	[no test files]
ok  	github.com/openshift/odo/pkg/application	0.329s
ok  	github.com/openshift/odo/pkg/application/labels	0.052s
?   	github.com/openshift/odo/pkg/auth	[no test files]
ok  	github.com/openshift/odo/pkg/catalog	0.224s
ok  	github.com/openshift/odo/pkg/component	0.531s
ok  	github.com/openshift/odo/pkg/component/labels	0.079s
ok  	github.com/openshift/odo/pkg/config	0.356s
ok  	github.com/openshift/odo/pkg/debug	0.694s
?   	github.com/openshift/odo/pkg/devfile	[no test files]
ok  	github.com/openshift/odo/pkg/devfile/adapters	0.425s
ok  	github.com/openshift/odo/pkg/devfile/adapters/common	0.238s
?   	github.com/openshift/odo/pkg/devfile/adapters/kubernetes	[no test files]
ok  	github.com/openshift/odo/pkg/devfile/adapters/kubernetes/component	5.471s
ok  	github.com/openshift/odo/pkg/devfile/adapters/kubernetes/storage	0.272s
ok  	github.com/openshift/odo/pkg/devfile/adapters/kubernetes/utils	0.298s
?   	github.com/openshift/odo/pkg/devfile/convert	[no test files]
ok  	github.com/openshift/odo/pkg/devfile/validate	0.179s
ok  	github.com/openshift/odo/pkg/envinfo	0.216s
ok  	github.com/openshift/odo/pkg/kclient	4.028s
?   	github.com/openshift/odo/pkg/kclient/fake	[no test files]
?   	github.com/openshift/odo/pkg/localConfigProvider	[no test files]
?   	github.com/openshift/odo/pkg/log	[no test files]
?   	github.com/openshift/odo/pkg/log/fidget	[no test files]
?   	github.com/openshift/odo/pkg/machineoutput	[no test files]
ok  	github.com/openshift/odo/pkg/notify	0.089s [no tests to run]
ok  	github.com/openshift/odo/pkg/occlient	3.293s
?   	github.com/openshift/odo/pkg/odo/cli	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/application	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/catalog	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/catalog/describe	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/catalog/list	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/catalog/search	[no test files]
ok  	github.com/openshift/odo/pkg/odo/cli/catalog/util	0.253s
?   	github.com/openshift/odo/pkg/odo/cli/component	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/component/ui	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/config	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/debug	[no test files]
ok  	github.com/openshift/odo/pkg/odo/cli/env	0.246s
?   	github.com/openshift/odo/pkg/odo/cli/login	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/logout	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/plugins	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/preference	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/project	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/registry	[no test files]
ok  	github.com/openshift/odo/pkg/odo/cli/registry/util	0.070s
ok  	github.com/openshift/odo/pkg/odo/cli/service	0.291s
ok  	github.com/openshift/odo/pkg/odo/cli/service/ui	0.165s
ok  	github.com/openshift/odo/pkg/odo/cli/storage	0.244s
?   	github.com/openshift/odo/pkg/odo/cli/telemetry	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/ui	[no test files]
?   	github.com/openshift/odo/pkg/odo/cli/url	[no test files]
ok  	github.com/openshift/odo/pkg/odo/cli/utils	0.186s
?   	github.com/openshift/odo/pkg/odo/cli/version	[no test files]
?   	github.com/openshift/odo/pkg/odo/genericclioptions	[no test files]
ok  	github.com/openshift/odo/pkg/odo/util	0.243s
ok  	github.com/openshift/odo/pkg/odo/util/completion	0.285s
ok  	github.com/openshift/odo/pkg/odo/util/experimental	0.055s
ok  	github.com/openshift/odo/pkg/odo/util/validation	0.058s
?   	github.com/openshift/odo/pkg/odogenerator	[no test files]
ok  	github.com/openshift/odo/pkg/preference	0.093s
ok  	github.com/openshift/odo/pkg/project	0.214s
ok  	github.com/openshift/odo/pkg/secret	0.222s
ok  	github.com/openshift/odo/pkg/segment	0.238s
ok  	github.com/openshift/odo/pkg/segment/context	0.213s
ok  	github.com/openshift/odo/pkg/service	0.176s
ok  	github.com/openshift/odo/pkg/storage	0.283s
ok  	github.com/openshift/odo/pkg/storage/labels	0.051s
ok  	github.com/openshift/odo/pkg/sync	0.093s
?   	github.com/openshift/odo/pkg/sync/mock	[no test files]
ok  	github.com/openshift/odo/pkg/testingutil	0.127s
?   	github.com/openshift/odo/pkg/testingutil/filesystem	[no test files]
?   	github.com/openshift/odo/pkg/unions	[no test files]
ok  	github.com/openshift/odo/pkg/url	1.061s
ok  	github.com/openshift/odo/pkg/url/labels	0.059s
ok  	github.com/openshift/odo/pkg/util	0.622s
?   	github.com/openshift/odo/pkg/version	[no test files]
ok  	github.com/openshift/odo/pkg/watch	30.193s
make prepare-release
./scripts/cross-compile.sh -mod=vendor -ldflags="-s -w -X github.com/openshift/odo/pkg/segment.writeKey=R1Z79HadJIrphLoeONZy5uqOjusljSwN -X github.com/openshift/odo/pkg/version.GITCOMMIT=aa90c53"
Cross compiling linux-amd64 and placing binary at dist/bin/linux-amd64/
Cross compiling linux-arm64 and placing binary at dist/bin/linux-arm64/
Cross compiling linux-ppc64le and placing binary at dist/bin/linux-ppc64le/
Cross compiling linux-s390x and placing binary at dist/bin/linux-s390x/
Cross compiling darwin-amd64 and placing binary at dist/bin/darwin-amd64/
Cross compiling windows-amd64 and placing binary at dist/bin/windows-amd64/
./scripts/prepare-release.sh
gzipping binary ./dist/bin/darwin-amd64/odo as ./dist/release/odo-darwin-amd64.tar.gz
odo
copying binary ./dist/bin/darwin-amd64/odo to release directory
gzipping binary ./dist/bin/linux-amd64/odo as ./dist/release/odo-linux-amd64.tar.gz
odo
copying binary ./dist/bin/linux-amd64/odo to release directory
gzipping binary ./dist/bin/linux-arm64/odo as ./dist/release/odo-linux-arm64.tar.gz
odo
copying binary ./dist/bin/linux-arm64/odo to release directory
gzipping binary ./dist/bin/linux-ppc64le/odo as ./dist/release/odo-linux-ppc64le.tar.gz
odo
copying binary ./dist/bin/linux-ppc64le/odo to release directory
gzipping binary ./dist/bin/linux-s390x/odo as ./dist/release/odo-linux-s390x.tar.gz
odo
copying binary ./dist/bin/linux-s390x/odo to release directory
zipping binary ./dist/bin/windows-amd64/odo.exe as ./dist/release/odo-windows-amd64.exe.zip
copying binary ./dist/bin/windows-amd64/odo.exe to release directory
generating SHA256_SUM for release packages
The SHA256 SUM for the release packages are:
c3e66fb7a4bc164024f22ca928037ad1d7c9c20f0fc5532653b5cc89889c859c odo-darwin-amd64.tar.gz
5a9fed484829d371459fe16207042992e8ccdbdb77e599fe6a5456706aa60fef odo-darwin-amd64
f32915e9171697888d7d5ad99273461f49d433e3e218cb34cb3c1c1dd2fdaa3b odo-linux-amd64.tar.gz
07d5f6a7f2670667cced06f18347f79150f1009dbd9c7a41bf3c4b59750b811f odo-linux-amd64
28186dcce8b51c9f6d7f8dc9d5e199df6ae96ffc640200fa64c766b57d1bffe1 odo-linux-arm64.tar.gz
f6662c893599d219ed2d780b7891244006a40f497b51d1a3e66d043064cd1c7c odo-linux-arm64
174d8edcd74955e87b8482a7d558acdb87511b7481fa8c0d8d3a42534788f2db odo-linux-ppc64le.tar.gz
92c914e33399171f9b5f8308ab50a65e73c3dc30b6893fd43ce1b7684db13adf odo-linux-ppc64le
aaaeeb5b4da93286bad27d55158e461c329fa470cfca37ae778f6799b3a5bbbc odo-linux-s390x.tar.gz
a48918a7708a9ebcdde6155c06d4982c8659c9b4037eaeb0b67a3f1d21968120 odo-linux-s390x
06493bf17dbcb9dc36824751e78b2c55604f6b836c42a1745a22b1a42bf3f140 odo-windows-amd64.exe.zip
70e84329b19e5d3b721ced10fef5fcec612f63c13e088f1a8816b5c142c60e11 odo-windows-amd64.exe
echo 2.2.4
unlink /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD/gocode/src/github.com/openshift/odo
exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.gugsC5
umask 022
cd /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD
'[' /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64 '!=' / ']'
rm -rf /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64
++ dirname /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64
mkdir -p /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT
mkdir /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64
cd openshift-odo-2.2.4-1
mkdir -p /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64//usr/bin
++ go env GOARCH
install -m 0755 dist/bin/linux-amd64/odo /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/bin/odo
mkdir -p /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share
install -d /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable
install -p -m 755 dist/release/odo-linux-amd64 /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-linux-amd64
install -p -m 755 dist/release/odo-linux-arm64 /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-linux-arm64
install -p -m 755 dist/release/odo-linux-ppc64le /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-linux-ppc64le
install -p -m 755 dist/release/odo-linux-s390x /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-linux-s390x
install -p -m 755 dist/release/odo-darwin-amd64 /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-darwin-amd64
install -p -m 755 dist/release/odo-windows-amd64.exe /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-windows-amd64.exe
cp -avrf dist/release/odo-darwin-amd64.tar.gz dist/release/odo-linux-amd64.tar.gz dist/release/odo-linux-arm64.tar.gz dist/release/odo-linux-ppc64le.tar.gz dist/release/odo-linux-s390x.tar.gz /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable
'dist/release/odo-darwin-amd64.tar.gz' -> '/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-darwin-amd64.tar.gz'
'dist/release/odo-linux-amd64.tar.gz' -> '/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-linux-amd64.tar.gz'
'dist/release/odo-linux-arm64.tar.gz' -> '/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-linux-arm64.tar.gz'
'dist/release/odo-linux-ppc64le.tar.gz' -> '/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-linux-ppc64le.tar.gz'
'dist/release/odo-linux-s390x.tar.gz' -> '/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-linux-s390x.tar.gz'
cp -avrf dist/release/odo-windows-amd64.exe.zip /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable
'dist/release/odo-windows-amd64.exe.zip' -> '/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/odo-windows-amd64.exe.zip'
cp -avrf dist/release/SHA256_SUM /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable
'dist/release/SHA256_SUM' -> '/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/SHA256_SUM'
cp -avrf dist/release/VERSION /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable
'dist/release/VERSION' -> '/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/odo-redistributable/VERSION'
/usr/lib/rpm/check-buildroot
/usr/lib/rpm/brp-compress
Processing files: odo-2.2.4-1.el7.x86_64
Executing(%license): /bin/sh -e /var/tmp/rpm-tmp.Ppo0ti
umask 022
cd /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD
cd openshift-odo-2.2.4-1
LICENSEDIR=/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/licenses/odo-2.2.4
export LICENSEDIR
/usr/bin/mkdir -p /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/licenses/odo-2.2.4
cp -pr LICENSE /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/licenses/odo-2.2.4
exit 0
Provides: odo = 2.2.4 odo = 2.2.4-1.el7 odo(x86-64) = 2.2.4-1.el7
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit)
Obsoletes: odo <= 2.2.4
Processing files: odo-redistributable-2.2.4-1.el7.x86_64
Executing(%license): /bin/sh -e /var/tmp/rpm-tmp.MN3Q2v
umask 022
cd /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD
cd openshift-odo-2.2.4-1
LICENSEDIR=/go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/licenses/odo-redistributable-2.2.4
export LICENSEDIR
/usr/bin/mkdir -p /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/licenses/odo-redistributable-2.2.4
cp -pr LICENSE /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64/usr/share/licenses/odo-redistributable-2.2.4
exit 0
Provides: odo-redistributable = 2.2.4 odo-redistributable = 2.2.4-1.el7 odo-redistributable(x86-64) = 2.2.4-1.el7
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit)
Obsoletes: odo-redistributable <= 2.2.4
Checking for unpackaged file(s): /usr/lib/rpm/check-files /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64
Wrote: /go/src/github.com/openshift/origin/odo/dist/rpmbuild/SRPMS/odo-2.2.4-1.el7.src.rpm
Wrote: /go/src/github.com/openshift/origin/odo/dist/rpmbuild/RPMS/x86_64/odo-2.2.4-1.el7.x86_64.rpm
Wrote: /go/src/github.com/openshift/origin/odo/dist/rpmbuild/RPMS/x86_64/odo-redistributable-2.2.4-1.el7.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.0dQ1wI
umask 022
cd /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILD
cd openshift-odo-2.2.4-1
/usr/bin/rm -rf /go/src/github.com/openshift/origin/odo/dist/rpmbuild/BUILDROOT/odo-2.2.4-1.el7.x86_64
exit 0
Validating odo rpm
/go/src/github.com/openshift/origin/odo/dist/rpmtest/odo /go/src/github.com/openshift/origin/odo
./usr/bin/odo
./usr/share/licenses/odo-2.2.4
./usr/share/licenses/odo-2.2.4/LICENSE
98296 blocks
odo
? Help odo improve by allowing it to collect usage data. Read about our privacy statement: https://developers.redhat.com/article/tool-data-collection. You can change your preference later by changing the Consent? Help odo improve by allowing it to collect usage data. Read about our privacy statement: https://developers.redhat.com/article/tool-data-collection. You can change your preference later by changing the ConsentTelemetry preference. No
odo v2.2.4 (aa90c53)
/go/src/github.com/openshift/origin/odo
Validating odo-redistributable rpm
/go/src/github.com/openshift/origin/odo/dist/rpmtest/redistributable /go/src/github.com/openshift/origin/odo
./usr/share/licenses/odo-redistributable-2.2.4
./usr/share/licenses/odo-redistributable-2.2.4/LICENSE
./usr/share/odo-redistributable
./usr/share/odo-redistributable/SHA256_SUM
./usr/share/odo-redistributable/VERSION
./usr/share/odo-redistributable/odo-darwin-amd64
./usr/share/odo-redistributable/odo-darwin-amd64.tar.gz
./usr/share/odo-redistributable/odo-linux-amd64
./usr/share/odo-redistributable/odo-linux-amd64.tar.gz
./usr/share/odo-redistributable/odo-linux-arm64
./usr/share/odo-redistributable/odo-linux-arm64.tar.gz
./usr/share/odo-redistributable/odo-linux-ppc64le
./usr/share/odo-redistributable/odo-linux-ppc64le.tar.gz
./usr/share/odo-redistributable/odo-linux-s390x
./usr/share/odo-redistributable/odo-linux-s390x.tar.gz
./usr/share/odo-redistributable/odo-windows-amd64.exe
./usr/share/odo-redistributable/odo-windows-amd64.exe.zip
757014 blocks
odo-darwin-amd64
odo-darwin-amd64.tar.gz
odo-linux-ppc64le
odo-linux-ppc64le.tar.gz
odo-linux-arm64
odo-linux-arm64.tar.gz
odo-windows-amd64.exe
odo-windows-amd64.exe.zip
odo-linux-amd64
odo-linux-amd64.tar.gz
odo-linux-s390x
odo-linux-s390x.tar.gz
odo v2.2.4 (aa90c53)
/go/src/github.com/openshift/origin/odo

<\details>

Is the PR still relevant?

yes Dharmit, as we are not running rpm test on our PR, previously it was run on unit test but when we updated the golang version it was causing failure.
This PR should fix it for go 1.15.
@prietyc123 here is the logs that you I inside the containers with these changes

/lgtm

@prietyc123 This PR needs update. As per the recent conversation with @mohammedzee1000.
For golang 1.16 this particular solution will not  work for 1.16, I will make appropriate changes try it on local that are suggested by @mohammedzee1000.

@prietyc123 This PR needs update. As per the recent conversation with @mohammedzee1000.
For golang 1.16 this particular solution will not work for 1.16, I will make appropriate changes try it on local that are suggested by @mohammedzee1000.

Ahh, so it is specific to go 1.15 .
/lgtm cancel

Closing as this PR can't fix the failure.


fix(versions): update Activiti/activiti-cloud-example-chart-modeling versions

UpdateBot pushed helm dependency: activiti-cloud-modeling to: 7.1.48

UpdateBot commands:
updatebot push-version --kind helm activiti-cloud-modeling 7.1.48

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.jenkins-x-bot seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Citadel's SPIFFE-based cert should probably include the Subject DN

Is your feature request related to a problem? Please describe.
Certs generated by Citadel contain nothing but the Subject Alternative Name (SAN), in accordance with SPIFFE's view (https://github.com/spiffe/spiffe/issues/56 and https://github.com/spiffe/spiffe/pull/75/files).
This is a bit awkward for enterprise adopters that want to gradually introduce Istio into older infrastructure, which often (or near always) rely on the SubjectDN (O=something CN=something.else...).
Describe the solution you'd like
Citadel already allows for a const "O" entry using the --org flag.
We could probably include the same spiffe URI as the CN, which should be good enough for most cases.
I can't think of a specific issue that might arise, but I guess it can be configurable.
Describe alternatives you've considered
Destroying the corporate structure and retiring to a remote island.
Additional context
Excluding tests/flags, it's pretty much a one-liner. I'm just not sure it's in line with Istio's views on the subject, so opinions are welcome.
at: https://github.com/istio/istio/blob/91a85fa9917b45705d8a24ede6c1f167b61e4019/security/pkg/pki/util/generate_csr.go#L55
// GenCSRTemplate generates a certificateRequest template with the given options.
func GenCSRTemplate(options CertOptions) (*x509.CertificateRequest, error) {
	template := &x509.CertificateRequest{
		Subject: pkix.Name{
			Organization: []string{options.Org},
+++			CommonName: options.Host,
		},
	}

This is a bit awkward for enterprise adopters that want to gradually introduce Istio into older infrastructure

Hi, could you say a bit more about this older infrastructure. Presumably the infrastructure isn't able to parse the SAN extension field or URIs, correct? Additionally, the older code isn't going to be able to interpret the "spiffe://" URI format (otherwise it would just be updated to pluck the URI from the SAN field directly). Can you help us better understand the goal of copying the SPIFFE URI into the CN field?

cc @evan2645

Well, the systems I'm talking mostly verify clients with basic ACL/Whitelist based stuff.
So they'd have the basic capability to inspect a subject DN (signed by a trusted CA) and verify it, with no real parsing beyond that.
The full spiffe URI would just be like any other "service identity" string.

More specific example: most Java-based stuff (e.g. Kafka, Cassandra, other Apache stuff) usually default to the JDK's implementation of inspecting an X509 Principal.
For example, Kafka uses this: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/15ef6431fffc/src/share/classes/sun/security/x509/X509CertImpl.java#l1821
(basically the subject DN)
You can obviously swap most of those out without too much effort, but there's a mountain of systems we can't (/won't) touch.

All good, I'll try to clarify our case (and future uses).
The JDK does provide an easy way to extract SANs, but the standard behavior we find in most systems is identifying a client using the SubjectDN.
Specifically in Kafka, the default behavior for extracting a string-based ID from a session is here: https://github.com/apache/kafka/blob/65b5ccf6413369aa4f21c72abcdf31ca72a79b00/clients/src/main/java/org/apache/kafka/common/security/authenticator/DefaultKafkaPrincipalBuilder.java#L113
Which eventually gets to the JDK's SSLSessionImpl.getPeerPrincipal() (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/15ef6431fffc/src/share/classes/sun/security/ssl/SSLSessionImpl.java#l565), which returns peerCerts[0].getSubjectX500Principal(); - leading to the code in the comment above.
This identity is then checked against Kafka's basic ACL implementation, allowing you to specify things like ID:O=bla;CN=abcd-in-bla; can consume topic1, ID:O=bla2;CN=xyz-in-bla2; can produce to topic2;, etc.
As the names suggest, these are the default behaviors, and in Kafka's case - replacable.
You can provide a different jar with your own PrincipalBuilder and Authorizer to the Kafka broker, and identify/authorize clients however you'd like.
The case with other, non open source and not so actively maintained is very different, and sooner or later you run into LegacySystemX that whitelists post-handshake clients based on X500Principal and nothing else.
In these cases, if it finds the spiffe URI in the CN, it can just be regarded as any other internal client (non resolvable string) and whitelisted as such.
It's not an ideal usecase (obviously), but it seems like a logical bridge between the current (/old) standards and spiffe.
I can't speak for the correctness or implications of putting the actual spiffe URI itself in the CN - I don't know enough about that domain to really tell right from wrong. Ideally/eventaully, I guess there should be some way to configure how the CSR transforms into a SubjectDN.

As the names suggest, these are the default behaviors, and in Kafka's case - replacable.
You can provide a different jar with your own PrincipalBuilder and Authorizer to the Kafka broker, and identify/authorize clients however you'd like.

It seems like Kafka in particular is sufficiently extensible that we don't have to create a workaround for that system. It's been a useful example Java system to consider for the purposes of this discussion, but it appears that we could implement a way for Kafka to pluck out the URI SAN field of a certificate. Is that accurate?

The case with other, non open source and not so actively maintained projects is very different, and sooner or later you run into LegacySystemX that whitelists post-handshake clients based on X500Principal and nothing else.

I think I understand where you're going with this example, but it's honestly difficult to help without more specifics. Perhaps the foundational systems for those legacy apps would be extensible, even if the legacy app itself is not?
Some other things we should consider regarding this change request:
(1) Once we include a spiffe URI in the CN, we effectively can never remove it. Once the Citadel CA begins publishing certs with the spiffe URI in the CN, we should assume that some systems will rely on it. Therefore, this isn't a short-term, stopgap measure.
(2) Inclusion of the spiffe URI in the CN is not part of the spiffe SVID specification. It's not against the spec, but it's not part of it. The significance here is that including it in Citadel doesn't mean that other spiffe CAs will also decide to include it. Systems relying on the CN field may only ever work with a single CA system (Citadel). Both as Istio matures and the spiffe spec gains broader industry traction, we should assume that other CAs will be built to support the spiffe spec (but without CN field support).
(3) The PKI community is trying to move away from the unstructured CN field. It's been deprecated for a decade or so. Absent a sufficiently compelling specific use case which requires the CN field, we should err on the side of being compliant with outstanding (current) specifications.

It seems like Kafka in particular is sufficiently extensible that we don't have to create a workaround for that system. It's been a useful example Java system to consider for the purposes of this discussion, but it appears that we could implement a way for Kafka to pluck out the URI SAN field of a certificate. Is that accurate?

Well, kinda. The part about Kafka allowing this extension point is of course true.
My point was more about the default behavior of Kafka - until googling kafka spiffe comes up with more than here are some results with 'spiffe' omitted, people are going to use (and rely on) the common behaviors.
It's one of the most likely systems to be found in large enterprises, and as a result - extremely prone to be customized to the point of global uniqueness, immediately becoming a legacy system itself.
A good exercise in understanding the realities of productionized Kafka is counting fortune100 companies using Kafka versions older than 5 years.
If you allow multiple entries per company (e.g. running separate Kafka 0.7 and 0.8 clusters because of some inability to upgrade), you might end up with more than 100.

Once we include a spiffe URI in the CN, we effectively can never remove it.

I don't think the backwards compatibility aspect of it is that severe, feature flags / deprecation notices are still possible, although not ideal.
I do agree with the overall point (protecting Istio from day1-deprecated features), and the things I control (e.g. our internal Kafka, Cassandra, legacy stuff) can and probably will adapt to eventually read SAN.
Out of our internal scope, though - I know from experience that other firms, clients, banks, etc will brush off a change request to modify authentication behavior in almost every non-0day scenario.
We (and probably every financial firm on the planet) have at least one live session with a client using their home made encryption, and a 3 year old patch waiting to be deployed "when they're ready".
Perhaps this issue should have a corresponding issue in SPIFFE talking about how SVID can support a more gradual change.
If you feel they're not very likely to support that flexibility, I guess we can close this.

The SPIFFE spec has purposefully omitted text relating to the CN and other commonly-used fields in order to allow for "dual-use" certificates and migrations. There are a ton of existing systems utilizing various fields in the Subject (as you have noted), and we definitely don't want you to have to choose one or the other when trying to adopt SPIFFE.
So, as @justinburke has mentioned, the SPIFFE stance is use the CN as you please... however I think there are a few downsides to putting a SPIFFE ID in the CN. First, I think a lot of software has certain expectations of what to find in CN (e.g. a hostname), and a SPIFFE ID is likely a surprise. Will the Kafka ACL system accept a full SPIFFE ID as a value? They have :s and /s etc. I wouldn't be surprised to find breakage around this in various softwares for one reason or another. It would be good to ensure this actually works as intended before making any changes.
Second, in the general case, there are many folks for whom CN already has a meaning. If developers come to expect SPIFFE IDs in CN, minting dual use certs and migrating from a non-SPIFFE system to a SPIFFE system will be much more difficult. This is a concern that has been explicitly voiced by users in the SPIFFE community in reference to this github issue.
Finally, the current state represents a carrot in that "if you implement SAN URI, you can get SPIFFE compatibility". If we put SPIFFE IDs in CN, we will need a stick "you must implement SAN URI or your stuff will stop working". Given that PKI community is trying to move away from CN, putting a SPIFFE ID there feels kind of like a step backwards IMO.
All that said, I think that ultimately compatibility is in everyone's best interest. Historically, CN has been hostname... SPIFFE is trying to correct a lot of problems that have come from that, however if we are looking for CN compatibility, I'd prefer to see a hostname (i.e. a DNS name) there than a SPIFFE ID. I realize that this also brings its own challenges. If putting a SPIFFE ID in CN is absolutely necessary for compatibility, I'd strongly recommend it be optional and not the default. I doubt that the SPIFFE community will want to change the spec to address CN field directly, however we can raise the topic on our next community call if necessary.
Hope this helps.

Will the Kafka ACL system accept a full SPIFFE ID as a value? They have :s and /s etc. I wouldn't be surprised to find breakage around this in various softwares for one reason or another. It would be good to ensure this actually works as intended before making any changes.

Yeah, works with Kafka's basic ACL/Authorizer (no hostname verification).
I see the point though - switching the mentioned legacy systems to no-verification (for those  who require it) would have the same operational (bureaucratic) effort as just accepting SANs.
RE: everything else - points accepted, maybe we can rephrase the issue to focus on the real problem - adopting SPIFFE gradually, through some dual-use CA (and can Citadel provide that?).
Can/should Citadel allow some customization, so it lets users create dual-use certificates? i.e.:

Default - SPIFFE section remains as is, everything else defaults to empty excepts Org (as it is now)
User provides some set of flags / CRD - Citadel resolves a static config to some transformation t where t(flagConsts, certificateSigningRequest/serviceAccount) + SPIFFE = dual_use_cert (this is already precedented with the --org flag, albeit not dynamic)
User provides an endpoint for Citadel to query before signing - seems over the top.

If this isn't the way forward, how does a user get Istio + dual-use certs?
Is dropping Citadel for something home-grown but retaining all related Istio features possible/recommended?

cc @wenchenglu @wattli
I think the best way to solve this issue is to have a thorough discussion on next SPIFFE community meeting. Istio security can follow the decisions made on the meeting.
One side note: CN does not support multiple values; SAN supports multiple values. We should think about whether this is good enough for all the use cases.

I agree with @justinburke and @evan2645 's points. CN is something we want to get rid of and we don't want put it back in Citadel. Looking forward to the spiffe discussion.

Here's the Kafka PrincipalBuilder we're using right now - https://github.com/Traiana/kafka-spiffe-principal
As mentioned, with Kafka it's easy enough to plug in something else.
For other systems - I don't there's a way around some dual-use CA.

@adamglt
We have brought up this up on SPIFFE and Istio team meetings. We agree to have Citadel support encoding SPIFFE identity in the X.509 certificate Common Name field, with the following constraints:

Encoding identity in CN is not enabled by default. It is controlled by a flag (possibly Citadel command line flag).
Certificate SAN field always carries the SPIFFE identity, it is not affected by the flag.
We should start with minimal support. The flag controls encoding CN for all the certificates issued by Citadel.

adamglt, it will be appreciated if you or some one from your team can implement this feature. Otherwise, the implementation may take some time :)

Couple questions in #7629, probably easier to discuss there

Related to https://github.com/istio/istio/issues/40615 and https://github.com/istio/istio/issues/42114


tests/application: Refactor willTrackNewReleases & isTrackingLatestRelease to async await

Change-type: patch
Signed-off-by: Thodoris Greasidis<EMAIL_ADDRESS>
Contributor checklist

[ ] Includes tests
[ ] Includes typings
[ ] Includes updated documentation
[ ] Includes updated build output

@balena-ci I self-certify!


Under some edge-case circumstances, SignalR will stop processing DOM Updates for all sessions in Blazor (0.7.0) under ASP.NET Core (2.1) when encountering an runtime exception.

Describe the bug
I am using Blazor 0.7.0 and ASP.NET Core 2.1, my apologies if this has already been flagged or fixed.
Additionally I am using Kestrel by itself without an additional web-server in front of it.
When using server-side Blazor, if you stack dictionaries inline inside of a component to perform a key lookup and encounter a Dictionary KeyNotFoundException on the parent, SignalR will have a nervous breakdown and stop processing updates for ALL active and new sessions.
Kestrel itself does not hang but issues heartbeat warnings after some period of time and eventually after a long time SignalR resumes functioning correctly.
The behavior was completely resolved by using ContainsKey prior to the lookup. I don't know if this is the case with other exception types.
To Reproduce
e.g  <img src="http://s3.amazonaws.com/static-images/@(imageLookup[languageTable["en"].Agency])" />
Expected behavior
I expected an exception to be thrown and potentially affect the current session in some way, however it affects ALL SignalR sessions across the process and completely prevents any DOM updates from being issued.

This seems like this has been fixed.
If you hit this during prerendering, then the developer exception page will show the exception.
When I try your sample without prerendering, this will throw an exception - which is logged to the client console, and then disconnect the client.
We're looking to make error handling better in general in the future, but for now this is what's expected when rendering throws.


[release-0.20] breaks kind batch build up even more

Cherry-picked from https://github.com/aws/eks-anywhere-build-tooling/pull/4133
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/hold

/lgtm
/approve

/override hook-tooling-presubmit-amd64
/override hook-tooling-presubmit-arm64

/unhold


HDDS-10198. Improve Logging in AbstractFindTargetGreedy

What changes were proposed in this pull request?
Simple DEBUG level logging improvement for Container Balancer.
This jira is to improve logging around a Datanode being removed from the collection of potential targets in ContainerBalancer. This can help us understand why a particular Datanode wasn't chosen as a target for container move when we think it's the optimal choice.
A Datanode may not be selected in multiple situations - it has already had enough size moved into it and has reached the limit, doesn't follow placement policy, already has the container's replica etc. I saw a situation in which a particular Datanode was the best choice when considering network distance and was also a potential target, but balancer did not choose it. I want to debug why this happened and more logging will help with this.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-10198
How was this patch tested?
Existing tests.

@ashishkumar50 @Tejaskriya Can you please review?

LGTM

Thanks @siddhantsangwan for the patch, @ashishkumar50, @sodonnel, @TaiJuWu, @Tejaskriya for the review.


[Airbrake] [Staging] TypeError: String can't be coerced into Float

Airbrake error: #9018
Airbrake project: ETMoses
Error type: TypeError
Error message: TypeError: String can't be coerced into Float
Where: DelayedJob Worker
Occurred at: Oct 21, 2016 09:43:24 UTC
First seen at: Oct 21, 2016 09:43:24 UTC
Occurrences: 0 (0 since last deploy on Oct 20, 2016 08:56:46 UTC)
URL: <no information>
File: [PROJECT_ROOT]/app/models/business_case_costs.rb
Backtrace:
[PROJECT_ROOT]/app/models/business_case_costs.rb:9:in /
[PROJECT_ROOT]/app/models/business_case_costs.rb:9:in depreciation_costs
[PROJECT_ROOT]/app/models/business_case_costs.rb:3:in total_yearly_costs
[PROJECT_ROOT]/app/models/market/initial_costs/costs.rb:17:in block in calculate

Looks like someone turned technical_lifetime into a string in the gas_asset_list.
One moment please.

Comment from Airbrake: Resolved error reoccurred.


Create --version command to print osv-scanner version

Hi @another-rex, I just opened a PR for this feature here https://github.com/google/osv-scanner/pull/50. Can you analyze if it makes sense?


OTP error after its send success

Issue:
I'm encountering an issue where the OTP email is successfully sent, but I get a JSON parsing error in the frontend with the message:
csharp
Copy code
Syntax error: Unexpected token 'O', 'OTP email' is not valid JSON
The issue arises because the sendOtpEmail function in the mail.php script outputs a string (like "OTP email sent successfully.") directly, which breaks the JSON response from the PHP signup script.
Suggested Fix:
To resolve this, the sendOtpEmail function should return a true or false status instead of outputting any messages directly. Here’s the suggested fix:

Update sendOtpEmail Function:
Replace the echo statements in mail.php with return true for success and return false for failure, like this:

php
Copy code
isSMTP();
        $mail->Host = 'smtp.gmail.com';
        $mail->SMTPAuth = true;
        $mail->Username =<EMAIL_ADDRESS>        $mail->Password = 'your-app-password'; // Gmail App Password
        $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
        $mail->Port = 587;

        // Sender and recipient settings
<EMAIL_ADDRESS>'Dummy Backend');
        $mail->addAddress($email, $name);

        // Email content
        $mail->isHTML(true);
        $mail->Subject = 'Your OTP Code';
        $mail->Body = '
Your OTP Code
' . $otp . '

Credit: Zyron-Tech
';

        // Send email
        $mail->send();
        return true; // Return success
    } catch (Exception $e) {
        // Log or return error information
        error_log("Email send error: " . $mail->ErrorInfo);
        return false; // Return failure
    }
}
2. Update signup.php to Handle the Email Send Status:
Modify the signup script to check the return status of the sendOtpEmail function, like this:

php
Copy code
if ($result) {
    // Send OTP email
    if (sendOtpEmail($email, $username, $otp)) {
        echo json_encode(['status' => 'success', 'message' => 'Signup successful! Please check your email for the OTP.']);
    } else {
        echo json_encode(['status' => 'error', 'message' => 'Signup successful but failed to send OTP email.']);
    }
} else {
    echo json_encode(['status' => 'error', 'message' => 'Failed to register user']);
}
This should prevent any non-JSON output from breaking the response and improve error handling during email sending.

Issue: JSON Parsing Error in Frontend Due to Direct Output from sendOtpEmail
Comment by TonyFred-code:
While testing the OTP functionality, the OTP email sends successfully, but there's a JSON parsing error in the frontend:
Syntax error: Unexpected token 'O', 'OTP email' is not valid JSON
This issue occurs because the sendOtpEmail function in the mail.php script outputs a string directly (e.g., "OTP email sent successfully."), causing the JSON response from the signup script to break.
Fix Implemented
Issue Cause:
The sendOtpEmail function was outputting direct messages, interfering with the JSON format expected by the frontend.
Solution:
I modified the sendOtpEmail function to return true or false based on the success or failure of sending the email, instead of outputting messages directly. Additionally, we updated the signup.php script to handle these return values properly.
Changes Made:

Updated sendOtpEmail Function

Replaced echo statements with return true; for success and return false; for failure.

Modified signup.php Script

Handled the return value of sendOtpEmail to ensure only proper JSON responses are sent back to the frontend.
If the email fails to send, the response indicates that the signup was successful, but the OTP email sending failed.

Updated Code:
Here's the modified code for signup.php:
if ($result) {
    // Send OTP email
    if (sendOtpEmail($email, $username, $otp)) {
        echo json_encode(['status' => 'success', 'message' => 'Signup successful! Please check your email for the OTP.']);
    } else {
        echo json_encode(['status' => 'error', 'message' => 'Signup successful but failed to send OTP email.']);
    }
} else {
    echo json_encode(['status' => 'error', 'message' => 'Failed to register user']);
}


Mistakes in description of Upload a release asset

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/rest/releases/assets?apiVersion=2022-11-28#upload-a-release-asset
What changes are you suggesting?
I am researching on publishing release assets automatically in scripts nowadays and I found some problems in the topic of Upload a release asset.

Firstly, the request example of CURL uses the url of uploads.github.com/xxx, which is not unified with another cases (which use api.github.com/xxx more)
However, it's just a matter of inconsistent usage, not a big problem. I have successfully upload assets by imitating this example. I mentioned this beacuse this issue is related with my following problems.

The core issues are in the example of Github CLI.
When I imitate it to write my own command, it doesn't work
Here is the piece of my script
release_id=139062277

echo $release_id

# Upload Assets
packages_suffix=(deb sh tar.gz zip)
asset_content_type=(
  application/vnd.debian.binary-package
  application/x-sh
  application/gzip
  application/zip
)

for ((i = 0; i < 4; ++i))
do
    package=Kerbal-${tag}-Linux.${packages_suffix[i]}
    echo ${package}
    echo ${asset_content_type[i]}
    gh api \
      --method POST \
      -H "Accept: application/vnd.github+json" \
      -H "X-GitHub-Api-Version: 2022-11-28" \
      --hostname HOSTNAME \
      /repos/WentsingNee/Kerbal/releases/${release_id}/assets?name=${package} \
      -f<EMAIL_ADDRESS>    #curl -L \
      #-X POST \
      #-H "Accept: application/vnd.github+json" \
      #-H "Authorization: Bearer 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" \
      #-H "X-GitHub-Api-Version: 2022-11-28" \
      #-H "Content-Type: application/octet-stream" \
      #"https://uploads.github.com/repos/WentsingNee/Kerbal/releases/${release_id}/assets?name=${package}" \
      #--data-binary<EMAIL_ADDRESS>done

Here is the output and error messages:
139062277
Kerbal-2024.1.1-Linux.deb
application/vnd.debian.binary-package
field<EMAIL_ADDRESS>requires a value separated by an '=' sign
Kerbal-2024.1.1-Linux.sh
application/x-sh
field<EMAIL_ADDRESS>requires a value separated by an '=' sign
Kerbal-2024.1.1-Linux.tar.gz
application/gzip
field<EMAIL_ADDRESS>requires a value separated by an '=' sign
Kerbal-2024.1.1-Linux.zip
application/zip
field<EMAIL_ADDRESS>requires a value separated by an '=' sign

Yes, document of GitHub CLI says, -f flag should pass argument in key=value format.
  -f, --raw-field key=value   Add a string parameter in key=value format

BUT, what is the KEY should I use?
data, binary or data-binary just like CURL example did?
I don't know.

OK, let's assume the key is data
    gh api \
      --method POST \
      -H "Accept: application/vnd.github+json" \
      -H "X-GitHub-Api-Version: 2022-11-28" \
      --hostname HOSTNAME \
      /repos/WentsingNee/Kerbal/releases/${release_id}/assets?name=${package} \
      -f<EMAIL_ADDRESS>
and we've got the second problems:
Post "https://HOSTNAME/api/v3/repos/WentsingNee/Kerbal/releases/139062277/assets?name=Kerbal-2024.1.1-Linux.deb": net/http: TLS handshake timeout

It tried to do a Post to a wrong domain
What's the meaning of --hostname HOSTNAME here? For convenience of upload assets to GitLab?
OK, let's fill in the correct HOSTNAME
application/vnd.debian.binary-package
{
  "message": "Not Found",
  "documentation_url": "https://docs.github.com/rest"
}
gh: Not Found (HTTP 404)

We' ve got 404
Let's refer to the other examples:

there is no --hostname HOSTNAME, right?
I can't understand why it occurs in upload example
Additional information
No response

--hostname would be for GHES and similar, see https://cli.github.com/manual/

Hi @WentsingNee 👋 ! I'm asking our team about this, and will return once I have more information. Thanks for your patience 💛


MacOS Ventura update makes nixpacks update fail

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
When I attempt to update nixpacks through homebrew, I'm confronted by this error relating to Ruby.
brew upgrade nixpacks
==> Upgrading 1 outdated package:
railwayapp/tap/nixpacks 0.10.5 -> 0.11.1
==> Downloading https://github.com/railwayapp/nixpacks/releases/latest/download/nixpacks-v0.11.1-x86_64-apple-dar
Already downloaded: /Users/nagybotond/Library/Caches/Homebrew/downloads/6b95ce78cbcd2f29fd7f2d6bdf3b8990cb58b0c78e777ceba0f6d6ede40a9b4e--nixpacks-v0.11.1-x86_64-apple-darwin.tar.gz
==> Upgrading railwayapp/tap/nixpacks
  0.10.5 -> 0.11.1

/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:12: warning: already initialized constant Gem::VERSION
/Library/Ruby/Site/2.6.0/rubygems.rb:11: warning: previous definition of VERSION was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/compatibility.rb:14: warning: already initialized constant Gem::RubyGemsVersion
/Library/Ruby/Site/2.6.0/rubygems/compatibility.rb:15: warning: previous definition of RubyGemsVersion was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/compatibility.rb:18: warning: already initialized constant Gem::RbConfigPriorities
/Library/Ruby/Site/2.6.0/rubygems/compatibility.rb:18: warning: previous definition of RbConfigPriorities was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/compatibility.rb:27: warning: constant Gem::ConfigMap is deprecated
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/compatibility.rb:35: warning: constant Gem::ConfigMap is deprecated
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/defaults.rb:3: warning: already initialized constant Gem::DEFAULT_HOST
/Library/Ruby/Site/2.6.0/rubygems/defaults.rb:3: warning: previous definition of DEFAULT_HOST was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:117: warning: already initialized constant Gem::RUBYGEMS_DIR
/Library/Ruby/Site/2.6.0/rubygems.rb:115: warning: previous definition of RUBYGEMS_DIR was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:122: warning: already initialized constant Gem::WIN_PATTERNS
/Library/Ruby/Site/2.6.0/rubygems.rb:129: warning: previous definition of WIN_PATTERNS was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:131: warning: already initialized constant Gem::GEM_DEP_FILES
/Library/Ruby/Site/2.6.0/rubygems.rb:138: warning: previous definition of GEM_DEP_FILES was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:141: warning: already initialized constant Gem::REPOSITORY_SUBDIRECTORIES
/Library/Ruby/Site/2.6.0/rubygems.rb:148: warning: previous definition of REPOSITORY_SUBDIRECTORIES was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:153: warning: already initialized constant Gem::REPOSITORY_DEFAULT_GEM_SUBDIRECTORIES
/Library/Ruby/Site/2.6.0/rubygems.rb:161: warning: previous definition of REPOSITORY_DEFAULT_GEM_SUBDIRECTORIES was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:162: warning: already initialized constant Gem::READ_BINARY_ERRORS
/Library/Ruby/Site/2.6.0/rubygems.rb:169: warning: previous definition of READ_BINARY_ERRORS was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:172: warning: already initialized constant Gem::WRITE_BINARY_ERRORS
/Library/Ruby/Site/2.6.0/rubygems.rb:174: warning: previous definition of WRITE_BINARY_ERRORS was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:185: warning: already initialized constant Gem::LOADED_SPECS_MUTEX
/Library/Ruby/Site/2.6.0/rubygems.rb:181: warning: previous definition of LOADED_SPECS_MUTEX was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:1345: warning: already initialized constant Gem::MARSHAL_SPEC_DIR
/Library/Ruby/Site/2.6.0/rubygems.rb:1319: warning: previous definition of MARSHAL_SPEC_DIR was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/version.rb:157: warning: already initialized constant Gem::Version::VERSION_PATTERN
/Library/Ruby/Site/2.6.0/rubygems/version.rb:157: warning: previous definition of VERSION_PATTERN was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/version.rb:158: warning: already initialized constant Gem::Version::ANCHORED_VERSION_PATTERN
/Library/Ruby/Site/2.6.0/rubygems/version.rb:158: warning: previous definition of ANCHORED_VERSION_PATTERN was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/requirement.rb:17: warning: already initialized constant Gem::Requirement::OPS
/Library/Ruby/Site/2.6.0/rubygems/requirement.rb:12: warning: previous definition of OPS was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/requirement.rb:27: warning: already initialized constant Gem::Requirement::SOURCE_SET_REQUIREMENT
/Library/Ruby/Site/2.6.0/rubygems/requirement.rb:22: warning: previous definition of SOURCE_SET_REQUIREMENT was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/requirement.rb:30: warning: already initialized constant Gem::Requirement::PATTERN_RAW
/Library/Ruby/Site/2.6.0/rubygems/requirement.rb:25: warning: previous definition of PATTERN_RAW was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/requirement.rb:35: warning: already initialized constant Gem::Requirement::PATTERN
/Library/Ruby/Site/2.6.0/rubygems/requirement.rb:30: warning: previous definition of PATTERN was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/requirement.rb:40: warning: already initialized constant Gem::Requirement::DefaultRequirement
/Library/Ruby/Site/2.6.0/rubygems/requirement.rb:35: warning: previous definition of DefaultRequirement was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/requirement.rb:314: warning: already initialized constant Gem::Version::Requirement
/Library/Ruby/Site/2.6.0/rubygems/requirement.rb:311: warning: previous definition of Requirement was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/platform.rb:198: warning: already initialized constant Gem::Platform::RUBY
/Library/Ruby/Site/2.6.0/rubygems/platform.rb:204: warning: previous definition of RUBY was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/platform.rb:204: warning: already initialized constant Gem::Platform::CURRENT
/Library/Ruby/Site/2.6.0/rubygems/platform.rb:210: warning: previous definition of CURRENT was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/stub_specification.rb:9: warning: already initialized constant Gem::StubSpecification::PREFIX
/Library/Ruby/Site/2.6.0/rubygems/stub_specification.rb:9: warning: previous definition of PREFIX was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/stub_specification.rb:12: warning: already initialized constant Gem::StubSpecification::OPEN_MODE
/Library/Ruby/Site/2.6.0/rubygems/stub_specification.rb:12: warning: previous definition of OPEN_MODE was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/stub_specification.rb:18: warning: already initialized constant Gem::StubSpecification::StubLine::NO_EXTENSIONS
/Library/Ruby/Site/2.6.0/rubygems/stub_specification.rb:18: warning: previous definition of NO_EXTENSIONS was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/stub_specification.rb:21: warning: already initialized constant Gem::StubSpecification::StubLine::REQUIRE_PATHS
/Library/Ruby/Site/2.6.0/rubygems/stub_specification.rb:21: warning: previous definition of REQUIRE_PATHS was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/stub_specification.rb:31: warning: already initialized constant Gem::StubSpecification::StubLine::REQUIRE_PATH_LIST
/Library/Ruby/Site/2.6.0/rubygems/stub_specification.rb:31: warning: previous definition of REQUIRE_PATH_LIST was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/specification_policy.rb:4:in `<top (required)>': superclass mismatch for class SpecificationPolicy (TypeError)
	from /Library/Ruby/Site/2.6.0/rubygems/core_ext/kernel_require.rb:85:in `require'
	from /Library/Ruby/Site/2.6.0/rubygems/core_ext/kernel_require.rb:85:in `require'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/specification.rb:16:in `<top (required)>'
	from /Library/Ruby/Site/2.6.0/rubygems/core_ext/kernel_require.rb:85:in `require'
	from /Library/Ruby/Site/2.6.0/rubygems/core_ext/kernel_require.rb:85:in `require'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:1365:in `<module:Gem>'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:116:in `<top (required)>'
	from /Library/Ruby/Site/2.6.0/rubygems/core_ext/kernel_require.rb:85:in `require'
	from /Library/Ruby/Site/2.6.0/rubygems/core_ext/kernel_require.rb:85:in `require'
	from /opt/homebrew/Library/Homebrew/utils/gems.rb:47:in `setup_gem_environment!'
	from /opt/homebrew/Library/Homebrew/standalone/load_path.rb:13:in `<top (required)>'
	from /opt/homebrew/Library/Homebrew/startup.rb:6:in `require_relative'
	from /opt/homebrew/Library/Homebrew/startup.rb:6:in `<top (required)>'
	from /opt/homebrew/Library/Homebrew/global.rb:4:in `require_relative'
	from /opt/homebrew/Library/Homebrew/global.rb:4:in `<top (required)>'
	from /opt/homebrew/Library/Homebrew/build.rb:11:in `require_relative'
	from /opt/homebrew/Library/Homebrew/build.rb:11:in `<main>'
Error: Failure while executing; `/usr/bin/sandbox-exec -f /private/tmp/homebrew20221026-96368-fxf5oq.sb nice /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby -W1 -- /opt/homebrew/Library/Homebrew/build.rb /opt/homebrew/Library/Taps/railwayapp/homebrew-tap/nixpacks.rb` exited with 1.

To reproduce

use command brew upgrade nixpacks

Expected behavior
Updates successfully
Environment
Nixpacks version: 0.11.1
MacOS Version: 13.0

This might not be a Nixpacks issue and more of a Homebrew issue. Are you able to upgrade any other brew packages?

Very strange, Nixpacks does not use Ruby at all so I am a little perplexed by that error message. If anyone else has this issue with Ventura please leave a comment.

This is probably a brew error, not a nixpacks error. Brew uses ruby, which explains why its complaining about ruby.

the fix probably is to update xcode dev tools. do this by uninstalling and reinstalling. (not sure tho, i'm not using ventura atm, and i havent experienced this issue)
sudo rm -rf /Library/Developer/CommandLineTools
xcode-select --install

@es183923 I tried doing that, didn't work.
I was thinking maybe the reason is that since that Xcode 14 wasn't released with Ventura, people who upgraded are forced to download either the beta release or the one of the RC's and maybe those have something Ruby related missing

Having the same issue while installing elasticsearch "superclass mismatch for class SpecificationPolicy"

I got the same superclass mismatch for class SpecificationPolicy error when trying to brew upgrade a different package.
Running commands to "clean up" Mac's system Ruby resolved the error for me, though I'm not entirely sure why. See https://stackoverflow.com/questions/74294323/superclass-mismatch-for-class-specificationpolicy/74296648#74296648
Or run:
sudo rm -rf \
  /Library/Ruby/Gems/2.6.0/{build_info,cache,doc,extensions,gems} \
  /Library/Ruby/Gems/2.6.0/specifications/*.gemspec \
  /Library/Ruby/Site

@troyshu Thanks, that fixes it


Optimize use of local variables use in BIR

Description:
Some of the local variables declared in the BIR can be reused. This can reduce the number of instructions generated in the byte code representation.
Steps to reproduce:
Consider the following ballerina code:
public function main() {
    int a = 3;
    int c = a + 2;
    int d = c + 1;
}

The bir generated code is as follows:
public main function() -> () {
    %0(RETURN) ();
    %1(LOCAL) int;
    %3(LOCAL) int;
    %5(TEMP) int;
    %7(LOCAL) int;
    %9(TEMP) int;

    bb0 {
        %1 = ConstLoad 3;
        %5 = ConstLoad 2;
        %3 = %1 + %5;
        %9 = ConstLoad 1;
        %7 = %3 + %9;
        %0 = ConstLoad 0;
        GOTO bb2;
    }
    bb1 {
        GOTO bb2;
    }
    bb2 {
        return;
    }
}

This can be optimized to reuse the local variables as follows:
public main function() -> () {
    %0(RETURN) ();
    %1(LOCAL) int;
    %3(LOCAL) int;
    %5(TEMP) int;

    bb0 {
        %1 = ConstLoad 3;
        %5 = ConstLoad 2;
        %3 = %1 + %5;
        %1 = ConstLoad 1;
        %5 = %3 + %1;
        %0 = ConstLoad 0;
        GOTO bb2;
    }
    bb1 {
        GOTO bb2;
    }
    bb2 {
        return;
    }
}

This would reduce two of the local variables and hence the number of generated instructions.
Affected Versions:
2.0.0-SNAPSHOT
Related Issues (optional):
https://github.com/ballerina-platform/ballerina-lang/issues/23376

The fix would involve liveness analysis with registry allocation at the bir gen phase

The actual optimization for the above function is as follows, because we don't reuse local variables:
public main function() -> () {
    %0(RETURN) ();
    %0(RETURN) ();
    %1(LOCAL) int;
    %3(LOCAL) int;
    %5(TEMP) int;
    %7(LOCAL) int;

    bb0 {
        %1 = ConstLoad 3;
        %5 = ConstLoad 2;
        %3 = %1 + %5;
        %5 = ConstLoad 1;
        %7 = %3 + %5;
        %0 = ConstLoad 0;
        GOTO bb2;
    }
    bb1 {
        GOTO bb2;
    }
    bb2 {
        return;
    }
}

Notice that variable %5 is reused


Add AutoMM backend to ag.vision

Issue #, if available:
NA
Description of changes:

Given deprecation of ag.vision in v0.7, we would like to give users the option to try MultiModalPredictor in ag.vision first. Simply call predictor = ImagePredictor(backend='automm') will do the trick.
Add fit_summary() to be consistent with tabular and timeseries predictor

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

This PR is working at this moment, @sxjscience @zhiqiangdon @FANGAreNotGnu , let me know if you think this solution is ok. Then I will work on adding backend for object detector in ag.vision.


[PDI-14132] About screen - information of GA, build version is out of…

… screen. Update according comment.

@e-cuellar, could you review it?


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_75qg13up3h/clone/recipe/meta.yaml:14: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_75qg13up3h/clone/recipe/meta.yaml:20: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_75qg13up3h/clone/recipe/meta.yaml:26: missing_pip_check: For pypi packages, pip check should be present in the test commands
ERROR: /tmp/abs_75qg13up3h/clone/recipe/meta.yaml:34: missing_dev_url: The recipe is missing a dev_url
WARNING: /tmp/abs_75qg13up3h/clone/recipe/meta.yaml:34: missing_description: The recipe is missing a description
Errors were found


Make bootloader buildable with -Zbuild-std

This switches the bootloader build from cargo-xbuild to cargo build -Zbuild-std=core. It uses the new package.metadata.bootloader.build-std key of version 0.8.1 of bootimage for that.
This change is non-breaking since the bootloader continues to be buildable with cargo-xbuild.

Published as v0.9.7.


Sonar: fix some issues

Fix:

https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_mzvNQXsxhzEr_e&resolved=false&types=CODE_SMELL
https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_q9vNQXsxhzEr_o&resolved=false&types=CODE_SMELL
https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_q9vNQXsxhzEr_q&resolved=false&types=CODE_SMELL
https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_q9vNQXsxhzEr_r&resolved=false&types=CODE_SMELL
https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_rJvNQXsxhzEr_s&resolved=false&types=CODE_SMELL
https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_rJvNQXsxhzEr_t&resolved=false&types=CODE_SMELL
https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_rJvNQXsxhzEr_u&resolved=false&types=CODE_SMELL
https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_rJvNQXsxhzEr_v&resolved=false&types=CODE_SMELL
https://sonarcloud.io/project/issues?id=jhipster_jhipster-quarkus&open=AXfZp_rqvNQXsxhzEr_w&resolved=false&types=CODE_SMELL

@qmonmert Can you fix the lint errors? I will merge your PR just after.

@avdev4j eslint does not agree with my changes :/

I have added the // eslint-disable-next-line no-restricted-syntax annotation before the second loop because using forEach instead is not possible because we can't break this kind of loop :(
I don't think there is any other solution.


FAQ 2001

Where to find the issue

FAQ 2001
https://www.coronawarn.app/en/faq/#cause2001
https://www.coronawarn.app/de/faq/#cause2001
Describe the issue

Suggested change

see https://github.com/corona-warn-app/cwa-app-android/issues/968#issuecomment-787214377
restart might be necessary..

Suggestion based on user comment corona-warn-app/cwa-app-android#968 (comment):
Add fourth bullet point:
"

In some cases, it is necessary to restart the device
"

Hello! I see that the FAQ posts have already been updated to inform users of the firewall settings fix, but not of the restart and mobile data fixes. If you'd like me add them then I'd be glad to help.

@amouzayanni I think you can go ahead and add this information to the FAQ, I (as a community contributor) don't see any points speaking against this.
An "official" statement from @dsarkar or another member of the @Open-Soruce-Team would still be good.

Sorry for the late response on my end! Just want to clarify that I'm no longer going to work on this issue.

An "official" statement from @dsarkar or another member of the @Open-Soruce-Team would still be good.

We think that the missing information can be added to the FAQ. I will prepare a PR soon.


Add flake8 configuration, address flake8 complaints

Prepare source code for release of a new version (1.5).

flake8 configuration (flake8 can then simply be run from the project root)
address all flake8 complaints (with the exception of a single complexity complaint)
update version number to 1.5 (for releasing / uploading to PyPI)

Closes issue #23.

Most awesome, thanks! I'll check this out in 10 days.

Scratch that - I don't want to keep this waiting. I'll check it out tonight.

Many thanks @bittner! I'm going to add one more tiny fix and you're free to push 1.5 to pypi.


publish to NPM as package

adding this to the official NPM as a package.

The package has been published to the official NPM repository.
https://www.npmjs.com/package/gathertown.js


geometry2: 0.5.13-0 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository geometry2 to 0.5.13-0:

upstream repository: https://github.com/ros/geometry_experimental.git
release repository: https://github.com/ros-gbp/geometry2-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.5.21
previous version for package: null

geometry_experimental
* Remove LGPL from license tags
  LGPL was erroneously included in 2a38724. As there are no files with it
  in the package.
* add missing dependencies in the meta-package geometry_experimental
  This partly fixes the doc jobs in #120 <https://github.com/ros/geometry_experimental/issues/120>
* Contributors: Jochen Sprickerhof, Vincent Rabaud

tf2

No changes

tf2_bullet
* Don't export catkin includes
  They only point to the temporary include in the build directory.
* Contributors: Jochen Sprickerhof

tf2_eigen
* Added missing inline
* Added unit test
  - Testing conversion to msg forward/backward
* Added eigenTotransform function
* Contributors: Davide Tateo, boris-il-forte

tf2_geometry_msgs
* Add missing python_orocos_kdl dependency
* make example into unit test
* vector3 not affected by translation
* Contributors: Daniel Claes, chapulina

tf2_kdl
* converting python test script into unit test
* Don't export catkin includes
* Contributors: Jochen Sprickerhof, Tully Foote

tf2_msgs

No changes

tf2_py

No changes

tf2_ros
* fix documentation warnings
* Adding tests to package
* Contributors: Laurent GEORGE, Vincent Rabaud

tf2_sensor_msgs
* add missing Python runtime dependency
* fix wrong comment
* Adding tests to package
* Fixing do_transform_cloud for python
  The previous code was not used at all (it was a mistake in the __init__.py so
  the do_transform_cloud was not available to the python users).
  The python code need some little correction (e.g there is no method named
  read_cloud but it's read_points for instance, and as we are in python we can't
  use the same trick as in c++ when we got an immutable)
* Contributors: Laurent GEORGE, Vincent Rabaud

tf2_tools
* casted el to string in view_frames
* Contributors: g_gemignani

geometry_experimental removed from kinetic

+1


add stony tomb, pit, arachnid lair

handle some path not found problem

Currently noticing the player is having a hard time entering spider cave. She will teleport onto the entrance, try to click but before she can successfully interact with the entrance, teleport away.
Suspecting the iteration is too quick, causing the program to get the old location data, while ingame character had just teleported on top of the entrance.

Let's merge the new runs, that is the root purpose of this PR. Could you please create a different PR for the movement/panic recover thing? It would be good if we can merge both things separate.
Thanks.


better logo that look more modern an will wlook good as fav.ico

Hi there, i made a better logo for your project. your new logo that you merged 11 days ago will not look good as fav.ico on your web beacuse its dimension is too high
I made a better modern logo, feel free to use it if you like it

Thanks! If you agree to release your logo under MIT license, please feel
free to make a Pull Request to submit your logo in "logo" folder. An ".svg"
file is required for a logo, other formats are optional, and not
recommended in PR.
On Thu, Mar 29, 2018 at 12:33 AM, linadesteem<EMAIL_ADDRESS>wrote:

Hi there, i made a better logo for your project. your new logo that you
merged 11 days ago will not look good as fav.ico on your web beacuse its
dimension is too high
I made a better modern logo, ell free to use it if you like it
[image: image]
https://user-images.githubusercontent.com/35618068/38075902-24e6688e-335e-11e8-9753-e168b63f437e.png
[image: image]
https://user-images.githubusercontent.com/35618068/38075906-2897656e-335e-11e8-83a2-0d91ddaafc4e.png
[image: image]
https://user-images.githubusercontent.com/35618068/38075913-2cfab322-335e-11e8-9587-4af03b1bce9c.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/evo-cloud/hmake/issues/107, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABq8Ujx8KA3CS5PPLE_uwiHqCB2akry5ks5tjI5lgaJpZM4S_4DL
.

Thanks sir, I agree to release it under MIT license and will make pupl request as soon as possible, may I know what is the requirements size of .svg file?

.svg is vector format. It doesn't matter what size you choose. We can always render a png from svg in any size without loosing quality. BTW, what's the original format of your logo? We require a vector format, otherwise we can scale it to arbitrary size. Thanks!

Thanks sir i will make pull request

It is a vector format sir. o can make it in .svg

@linadesteem thanks!


fix reference error of msg.status in debug node

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Proposed changes

If a debug node receives a message with msg.status = null it causes following error:
TypeError: Cannot read property 'hasOwnProperty' of null

This PR try to fix this isseue.
Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the forum/slack team.
[x] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage decreased (-0.03%) to 68.615% when pulling 226f45d8d5ab9f55dcdf66a3b24d9300503e8f5b on node-red-hitachi:fix-status-reference-in-debug-node into 0aa80d82d91eb8766242a4f7c93738b0c7197ec5 on node-red:master.


docs: Recommend title case not sentence case for list-of-links labels

In prototyping recent list-of-links usage with UX consultant @mrdahman , title case rather than sentence case seemed to be preferable for the within-list-of-links-type-widget link labels.

This is at odds with the style recommendation currently embedded in the widget documentation (though interestingly the example screenshot in the documentation is already using title case rather than sentence case for this labelling). This changeset would update the guidance to match what we seem to now be preferring.
Personally, I'd have gone with sentence case. But this isn't about me personally. :) So this PR is about reconciling what professionally we ought to be recommending.

Contributor License Agreement adherence:

[x] This Contribution is under the terms of Individual Contributor License Agreements (and also Corporate Contributor License Agreements to the extent applicable) appearing in the Apereo CLA roster.

I think a call to action looks better as title case. Sentence case without punctuation at the end is a little annoying to me personally, but more than that, I think it just looks more impressive. I admit I'm also biased by German immersion, which capitalizes liberally. :)

I don't want to throw a wrench in @mrdahman reco's but I'm still an advocate for sentence case, per Material Guidelines, and though it's hardly settled in terms of usability research, sentence case has strong advantages for read-ability. See https://medium.com/@jsaito/making-a-case-for-letter-case-19d09f653c98.

I think this is the right soul-searching to be prompting, albeit over an elongated time period so that @mrdahman can enjoy her justly earned leave this week and re-engage next week or so. :)
Stipulating that our current realization of Material Design is imperfect and as much aspirational as it is achieved, this is another one of those opportunities to decide: are we literally adopting Material Design, as best we can, and of course layering on local considerations and working within its extensibility for typography and branding? Or are we working towards our own design system somewhat inspired by Material Design? I see efficiencies, leverage to be gained in the former.

That's a great point @prtreige . Readability is a concern with title case, though somehow in the specific example of the widget we were looking at, the two documents that we put in title case were easier to understand in title case than sentence case. Perhaps in that instance it was more of an example of a proper noun, i.e., a named document. (Also, as an aside, the character limit on the list of links widgets doesn't allow us to write anything that would be too difficult to read in title case.) But yes, I agree that we run into the larger problem of how closely we are adhering to Material Design. And, @apetro , I fully acknowledge that there are efficiencies with literally adopting Material Design, but think there might also be some wiggle room if something feels easier to understand. Thoughts?

Hard cases make bad law.
I think the most important error here was my prematurely trying to generalize a change to the design system from one goofy list-of-links widget making exceptions to the design system. Too soon.
Let's

revert this specific changeset and drop the search-with-links parallel in #597 ,
keep the guidance we had (sentence case) (think of it as a nod to stare decisis)
accept the MyUW-local one-off ad-hoc title case usage in the one specific goofy widget because it's literally what we've been asked to do locally, temporarily accepting a little local MyUW weirdness to shield the open source product from turbulence
work more generally to really grapple with what our relationship to Material Design is and ought to be
revisit this when it comes up again. I imagine it will.


swift5.5 concurrency support (async await)

can use async/await in swift5.5(xcode13)
Package.swift in Target config.
swiftSettings: [
                .unsafeFlags([
                    "-Xfrontend", "-disable-availability-checking", // ignore concurrency api check
                    "-Xfrontend", "-enable-experimental-concurrency",
                ]),
            ]

and update TG Bot API 5.3 & fix generate_wrappers.rb

Awesome changes

and update TG Bot API 5.3 & fix generate_wrappers.rb

Do you want to be co-maintainer of this package? Please write me in telegram @givip

and update TG Bot API 5.3 & fix generate_wrappers.rb

Do you want to be co-maintainer of this package? Please write me in telegram @givip

yes. I'll contact you in telegram.


updated brew install command to reflect --cask

Received an error installing via HomeBrew
Error: Calling brew cask install is disabled! Use brew install [--cask] instead.
brew install --cask lepton
This is expected behavior. brew cask  was deprecated in favor of brew  --cask in Homebrew 2.6.0. Now that 2.7.0 has been released, they have been disabled. This was documented in the release notes and on the Homebrew blog in addition to the messages at the command-line

Other pull request are sufficient!

Other pull request are sufficient!


Readonly Databases not Supported (eg Dremio or lower permissioned connections)

Make sure these boxes are checked before submitting your issue - thank you!

[X] I have checked the superset logs for python stacktraces and included it here as text if any
[X] I have reproduced the issue with at least the latest released version of superset
[X] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
0.24
Expected results
I should be able to add a table from any database connection.  Note that when I add more database connections I can use them just fine in the SQL Lab UI - just can't add tables from them in the Tables function - so I can't actually use them in charts or dashboards.
It seems like the Superset system is only designed to use a single database at a time and requires read/write access to that database, which would block my planned use of the system where I planned to have a small postgresql database for metadata and management and a large readonly database (Dremio in my case) as the analytical datastore.
Actual results
When adding a new Table item in the UI the system gets confused and queries the target database to check if the "tables" table already contains the new entry - rather than checking the main database connection (sqlite in my case).   The system returns an Unknown error from database Flash message and the query itself fails in the Superset system logs (table "Tables" does not exist)
Steps to reproduce
Install the system as is with the Sqlite datasource/database as the primary database (load samples etc).   Then Add a new Database in addition to the SQLLite one.  In my case add a database where new tables cannot be created (although this seems to be beside the point).
Attempt to add a new Table that is known to exist in the secondary database.
Watch the system fail to add the new table (generating the unknown database flash message)
Appears to be a problem in (or leading up to)
superset/connectors/sqla/views.py line 236 pre_add method

This seems to grab the wrong database sqla engine value and implications are that the system needs to know which is the database engine that holds the Superset metadata and which is the system where the new table is to be added from.
SQL Trace
2018-04-30 20:14:20,274 INFO sqlalchemy.engine.base.Engine SELECT EXISTS (SELECT 1
FROM tables
WHERE tables.table_name = ? AND tables.schema = ? AND tables.database_id = ?) AS anon_1
2018-04-30 20:14:20,274:INFO:sqlalchemy.engine.base.Engine:SELECT EXISTS (SELECT 1
FROM tables
WHERE tables.table_name = ? AND tables.schema = ? AND tables.database_id = ?) AS anon_1
2018-04-30 20:14:20,275 INFO sqlalchemy.engine.base.Engine (u'sf_incidents_clean', u'', 3)
2018-04-30 20:14:20,275:INFO:sqlalchemy.engine.base.Engine:(u'sf_incidents_clean', u'', 3)
2018-04-30 20:14:20,275:INFO:root:Database.get_sqla_engine(). Masked URL: dremio+pyodbc://malsmith:XXXXXXXXXX@mydremio
2018-04-30 20:14:20,562 INFO sqlalchemy.engine.base.Engine ROLLBACK
2018-04-30 20:14:20,562:INFO:sqlalchemy.engine.base.Engine:ROLLBACK
2018-04-30 20:14:20,564:INFO:werkzeug:<IP_ADDRESS> - - [30/Apr/2018 20:14:20] "POST /tablemodelview/add HTTP/1.1" 302 -

You may want to raise debugging level to see more interesting things. Superset works perfectly fine with multiple databases. It looks like it's just matter of ironing out the compatibility with dremio.

I think you're misinterpreting the logs. Superset does not require writing to target databases. SELECT EXISTS is against your Superset metadata database as it should as it tries to add a new entry on the Superset side to store the table's metadata from Dremio.
My guess it that the call that tries to extract the metadata from Dremio here
https://github.com/apache/incubator-superset/blob/master/superset/models/core.py#L809
isn't working properly in the dialect.
Some database don't have a direct notion or schema, or sometimes have 2 levels of namespacing (Postgres has database and schema/owner) and that doesn't always fits the SQLAlchemy model perfectly. Dialects implementation have to be careful to line things up properly.

@malsmith how did you connect Dremio to Superset? Trying to do the same and don't see it supported, was considering trying to use the half baked Apache Drill connected for SQL Alchemy possibly but would love to see what you're doing.

@malsmith I'm very interested in connecting Dremio to Superset as well! Any advice welcome

@malsmith Same here! Would love any advice. 👍

Looks like Dremio has an ODBC driver and a SQLAlchemy dialect (https://github.com/sqggles/sqlalchemy_dremio), which means something like: dremio+pyodbc://malsmith:XXXXXXXXXX@mydremio may work.
You may have to add a new entry to configure Dremio in superset/db_engines_sepc.py, and depending on the maturity of the SQLA dialect you may need to tweak that as well.

@mistercrunch thanks Maxime! I'm going to try to get the SQL Alchemy dialect working, the team that built it abandoned the project BUT I think left it in a working or semi working state. If anyone else would rather try it out please let me know, I'm only able to work on this on the weekends but if I get it working I'll @ everyone who was interested here

Writing/tuning a SQLAlchemy dialect shouldn't be too hard, good luck!

@mistercrunch thanks Maxime! I'm going to try to get the SQL Alchemy dialect working, the team that built it abandoned the project BUT I think left it in a working or semi working state. If anyone else would rather try it out please let me know, I'm only able to work on this on the weekends but if I get it working I'll @ everyone who was interested here

I started working on connecting Dremio to Apache Superset. Want to check if you were able to connect it using SQLAlchemy dialect. Any advice will be helpful as I am new to Superset & dremio.

@mgoel1190 and @mistercrunch - I'm on another thread with someone who has revived the abandoned project and gotten it working, will @ him in here once I know his Github handle (he emailed me directly)

Ah! It's @timkessler

@mgoel1190 and @mistercrunch - I'm on another thread with someone who has revived the abandoned project and gotten it working, will @ him in here once I know his Github handle (he emailed me directly)

@tomasienrbc Thank you for your quick reply. Will check with Tim.

@timkessler I am very much interested in connecting Dremio with Apache superset using SQL alchemy dremio dialect. Can you please provide any guidance on how to do it.

@mgoel1190 I just started that repo this week.  I haven't had time to commit changes yet.  so, it's just a copy of of incubator-superset presently.  For now, you can take a look here at my notes on how I got it working:  https://github.com/apache/incubator-superset/issues/4192


Trinity config

This PR proposes to merge the new configuration subsystem into the mainline.
The new configuration subsystem supports Trinity Configuration File Version 2.0, while still compatible with 1.0.

Hi @yatli, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor. If you're full-time or an intern, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


Comments on Run on OS Login

Overall, I'm still a bit on the fence about whether this particular API is necessary on the web platform, but I don't want to block experimentation. Here are some comments on the explainer:
Scope
I think it should be noted in the explainer that this is a purely desktop functionality. Mobile OSs do not permit applications to be run on login / startup.
Availability
What restrictions are placed on calling the API to ensure it is not abused / spammy like permission prompts can be?
Additionally, trusting a web app to provide the ability to disable running on login seems somewhat optimistic. Is it worth strengthening the suggests that user agents provide a way for users to identify web apps that are running on OS login, and disabling them?
Mode
I'd suggest making this correspond to the web app manifest display-mode values and choose standalone to indicate opening in windowed mode.
Privacy

as it is already possible for native applications to be auto started

This is something of a disingenuous comparison since there is currently no way for a web site to request that it be started on login. Privacy considerations generally aren't about comparing to existing native functionality, but rather existing functionality on the web platform. Right now, users have to explicitly launch an installed web app; this functionality lets that web app start automatically, and that is new to the web platform.
I also think there is room for guidance to implementations here regarding the scope of what is automatically started. Most browsers have a "continue where you left off" type feature. Launching a web app at login should not also restart the browser and its previous tab state, as that greatly increases the scope of the sites able to observe the user for longer than they might expect.
Use of permissions API
As noted in #342, this is a rather unusual application of the permissions API for several reasons (ergonomics, non-availability in non-installed contexts). I'd strongly suggest not using the permissions API here since it's not a good fit.

Right now, users have to explicitly launch an installed web app; this functionality lets that web app start automatically, and that is new to the web platform.

This is not strictly true. As it is right now, there is an inter-browser incompatibility here that needs to be flushed out. For example, I can properly launch a PWA on Edge Canary during (MacOS) startup but not from Chrome Canary.

Steps to test (on MacOS):

Install a PWA ( https://airhorner.com will do for the test ) from Edge and Chrome.
Go to System Preferences > Users > Select your user > Login Items
Using the plus sign icon at the bottom of the application list, select $HOME/Applications/Chrome Canary Apps/The Air Horner to be added to startup
Logout
Login
Observe Chrome Canary starts along with the PWA instance, but neither show a window visible to the user. Canary will once clicked on, but the PWA is dead until quit and manually started.
Go back to the login items list in system preferences
Remove the Chrome Canary application and add the Edge Canary install in its place.
Logout
Login
See the PWA properly boot and show the window along with Edge Canary starting in the background.

So users can currently have a PWA start on login. It just depends on the exact browser being used whether it fully works or not. So we need to decide:

Is this is desired behavior?
Do we want to expose this to web developers so they can let users know it is possible and seamlessly allow it?

Personally I can see a discussion leading to us wanting to allow the behavior to happen, but for now possibly not expose a direct API for web apps. Instead leave it in settings and have the browser facilitate the OS level integrations needed. Then users as they wish can use the native facilities or browser settings to achieve the tasks. For example, the dock on MacOS allows users to right click, go to Options, then select "Open at login" to add/remove a login item.

Thanks for the comment. I think the "existing incompatibility" you have described is not exposed to the web platform, but rather a user explicitly modifying their system to change its behaviour in a way that the web cannot directly control.
An analogy might be saying that installed web apps already have the ability to resize their own window bounds because on Windows, the user can edit the command line invocation in the desktop shortcut to include ones which specifically set the window size. Technically, yes, users can edit what starts up on certain OSs manually. But the whole discussion here is about whether or not we should expose a new ability to the web platform: to explicitly set and control startup behaviour, and we should say as such in the privacy considerations rather than comparing to situations where users are changing the system beyond the reach of the web platform.
If we end up not exposing an API to the web, then there is less need for this discussion - it's focused on the impact of exposing new APIs to the web on the user. Instead, competitive forces drive whether other browsers adopt these features. :)

Ah, thanks for the follow-up context. I think I initially had one interpretation in my mind of the concern as I read it since it was under the Privacy header. You're coming from it a few degrees over from where my head space was at.
With this new understanding, I went to write a follow-up here. But it's gotten quite large and I don't want to deter from the other points you've brought up for discussion. So I'm going to flush that thought out more and make a new issue on the privacy considerations section to help improve it.
I would like to be clear on my remark of "now possibly not exposing an API." I think as a last resort if we can't find consensus on that aspect there is potential to move forward and decide on that later. That way we could at least have standardized behavior guidelines and expectations for browsers with this capability that is emerging as modern web applications become more integrated with the desktop.