This needs to be done by the repository owner: https://docs.renovatebot.com/getting-started/installing-onboarding/

It seems some registration with Mend / White Source Ltd is necessary to use the app. I'm wondering if all it does is maybe open a PR to the repo with more or less the same GitHub Action we already have, but instead setting "onboarding": true? This might be why it is the "recommended" installation method, because they get your contact data 😅

If you want to stick with the current docker action, I think something is misconfigured with the secret and/or associated permissions.

Hi there,

First, thanks for the job you do with this image, it's very appreciated.

Seems the github actions run did not complete successfully and thus, the 4.1.0 image is not available on github.

Cf https://github.com/rvolosatovs/docker-protobuf/actions/runs/5377667314

Could you please review and fix this ?

Thanks !

--rust_out: protoc-gen-rust: Plugin killed by signal 11.

Support for Python gRPC seems to be missing right now. It looks like it can be fetched by building this project: https://github.com/grpc/grpc Never mind, I see it is included already.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Location: .github/renovate.json
Error type: The renovate configuration file contains some invalid settings
Message: Invalid configuration option: includeForks

Summary:

Update Alpine to 3.9 and Go to 1.12.x

Why do we need this?

To be up to date

What is already there? What do you see now?

Outdated OS and package

What is missing? What do you want to see?

Updated OS and package

How do you propose to implement this?

Bump versions once grpc/grpc#18064 is fixed

Summary

Add a test

Why do we need this?

To ensure nothing breaks on updates or changes

What is missing? What do you want to see?

A test, which would run on each PR

How do you propose to implement this?

Run each protoc plugin against a (valid) proto file and ensure that execution succeeds.

Can you do this yourself and submit a Pull Request?

yes

protoc_plugin package installation fails on arm64 and building in QEMU is extremely slow - not sure what to do here

Summary

I'm working on a project and start to learn/use protobuf as protocol. After imported docker-protobuf layer, I saw this error. To simplify the situation, I recreated a new workspace and only a minimum context is involved.

Steps to Reproduce

1. Use a simple Dockerfile as below:
   $ cat Dockerfile
   FROM thethingsindustries/protoc:latest as protobuf
   ARG CENTOS_VERSION=7.7.1908
   FROM centos:$CENTOS_VERSION as osbase

2. Build it
   $ docker build .
   Sending build context to Docker daemon 16.38kB
   Step 1/3 : FROM thethingsindustries/protoc:latest as protobuf
   ---> 61425e1df8e3
   Step 2/3 : ARG CENTOS_VERSION=7.7.1908
   ---> Using cache
   ---> dc1d45376788
   Step 3/3 : FROM centos:$CENTOS_VERSION as osbase
   invalid reference format

3. Error shows at the last line above

What do you see now?

See the example I posted in the Reproduce section.

What do you want to see instead?

If I removed the first line, then I see the $CENTOS_VERSION is being parsed correctly.
$ docker build .
Sending build context to Docker daemon 16.38kB
Step 1/2 : ARG CENTOS_VERSION=7.7.1908
Step 2/2 : FROM centos:$CENTOS_VERSION as osbase
---> 08d05d1d5859
Successfully built 08d05d1d5859

Another, the doker-protobuf layer accepts ARG as tag itself. Here is another run:
$ docker build .
Sending build context to Docker daemon 16.38kB
Step 1/4 : ARG TTI_VERSION=3.1.22
Step 2/4 : FROM thethingsindustries/protoc:$TTI_VERSION as protobuf
---> 43f36b10febe
Step 3/4 : ARG CENTOS_VERSION=7.7.1908
---> Using cache
---> b51117ba064d
Step 4/4 : FROM centos:$CENTOS_VERSION as osbase
invalid reference format

Environment

The docker version on my MacOS. (however, I see the same thing on a Centos VM.)
$ docker version
Client: Docker Engine - Community
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:21:11 2020
OS/Arch: darwin/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.12)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:29:16 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683

How do you propose to implement this?

I've been using Docker for a while but very new to docker-protobuf. Not sure if this is an issue but it looks odd to me.

Can you do this yourself and submit a Pull Request?

...

Summary

I'm generating code for the grpc gateway.
It seems the codegen doesn't create the method: ProtoReflect

An extract of the proto file:

syntax = "proto3";

import "google/api/annotations.proto";

package proto;

option go_package = ".;proto";

service AddressService {
  rpc GetAddresses(GetAddressesRequest) returns(GetAddressesResponse) {
    option (google.api.http) = {
      get: "/address"
    };
  }
}

message AddressRequest {
  string addressUuid = 1;
  string firstname = 2;
  string lastname = 3;
  string company = 4;
  string line1 = 5;
  string line2 = 6;
  string entryCode = 7;
  string floor = 8;
  string zipCode = 9;
  string city = 10;
  string phone = 11;
  bool isDefault = 12;
}

message GetAddressesRequest {
}

message GetAddressesResponse {
  repeated AddressRequest addresses = 1;
}

I tried to upgrade the protoc-gen-tool and using the new repo, I have the same issue

ARG PROTOC_GEN_GO_VERSION
RUN mkdir -p ${GOPATH}/src/google.golang.org/protobuf && \
    curl -sSL https://api.github.com/repos/protocolbuffers/protobuf-go/tarball/v${PROTOC_GEN_GO_VERSION} | tar xz --strip 1 -C ${GOPATH}/src/google.golang.org/protobuf &&\
    cd ${GOPATH}/src/google.golang.org/protobuf && \
    go build -ldflags '-w -s' -o /golang-protobuf-out/protoc-gen-go ./cmd/protoc-gen-go && \
    install -Ds /golang-protobuf-out/protoc-gen-go /out/usr/bin/protoc-gen-go

protoc-gen-go --version
protoc-gen-go v1.27.1

Steps to Reproduce

I create a repo to reproduce the issue with some commands: https://github.com/kanobay/debug-grpc-gateway

What do you see now?

the full error on compilation:

# github.com/kanobay/amnesia/proto/gen
../proto/gen/address.pb.gw.go:182:44: cannot use &protoReq (type *AddressRequest) as type protoreflect.ProtoMessage in argument to runtime.PopulateQueryParameters:
        *AddressRequest does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:215:44: cannot use &protoReq (type *AddressRequest) as type protoreflect.ProtoMessage in argument to runtime.PopulateQueryParameters:
        *AddressRequest does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:249:40: cannot use resp (type protoiface.MessageV1) as type protoreflect.ProtoMessage in argument to forward_AddressService_GetAddresses_0:
        protoiface.MessageV1 does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:272:41: cannot use resp (type protoiface.MessageV1) as type protoreflect.ProtoMessage in argument to forward_AddressService_CreateAddress_0:
        protoiface.MessageV1 does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:295:41: cannot use resp (type protoiface.MessageV1) as type protoreflect.ProtoMessage in argument to forward_AddressService_UpdateAddress_0:
        protoiface.MessageV1 does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:318:41: cannot use resp (type protoiface.MessageV1) as type protoreflect.ProtoMessage in argument to forward_AddressService_DeleteAddress_0:
        protoiface.MessageV1 does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:379:40: cannot use resp (type protoiface.MessageV1) as type protoreflect.ProtoMessage in argument to forward_AddressService_GetAddresses_0:
        protoiface.MessageV1 does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:399:41: cannot use resp (type protoiface.MessageV1) as type protoreflect.ProtoMessage in argument to forward_AddressService_CreateAddress_0:
        protoiface.MessageV1 does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:419:41: cannot use resp (type protoiface.MessageV1) as type protoreflect.ProtoMessage in argument to forward_AddressService_UpdateAddress_0:
        protoiface.MessageV1 does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:439:41: cannot use resp (type protoiface.MessageV1) as type protoreflect.ProtoMessage in argument to forward_AddressService_DeleteAddress_0:
        protoiface.MessageV1 does not implement protoreflect.ProtoMessage (missing ProtoReflect method)
../proto/gen/address.pb.gw.go:439:41: too many errors 

What do you want to see instead?

Environment

I'm running the codegen inside the container of this repo on the version: rvolosatovs/protoc:3.2.0

How do you propose to implement this?

...

Can you do this yourself and submit a Pull Request?

...

Summary

protoc-gen-swiftof v3.1.26 splits no version information available error messages.
...

Steps to Reproduce

1. $ docker run --rm -it --name protoc --entrypoint /bin/sh thethingsindustries/protoc:3.1.26
2. $ protoc-gen-swift

What do you see now?

/ # protoc-gen-swift
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicuucswift.so.61)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicuucswift.so.61)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicui18nswift.so.61)
protoc-gen-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicui18nswift.so.61)

What do you want to see instead?

No error messages.

Environment

MacOS 10.15.5, Docker 2.3.0.3

How do you propose to implement this?

Can you do this yourself and submit a Pull Request?

Since #87 was merged, CI builds became extremely slow (over 5 hours)

See #87 (comment) for more details and suggestions on how to fix

Is there an existing issue for this?

• I have searched the existing issues

Description

Dynamic memory allocation is mandatory in protobuf-c, but it is a resource-consuming practice to use dynamic memory allocation in many embedded devices. Even some low-end chips do not support malloc operation, while nanopb can use static memory allocation to perform encoding and decoding operations, so we hope to add nanopb support.

Acceptance Criteria

No response

Suggestions for a technical implementation

https://github.com/nanopb/nanopb

#311 1.057 protoc-gen-gotemplate: program not found or is not executable
#311 1.057 Please specify a program using absolute path or make sure the program is available in your PATH system variable
#311 1.060 --gotemplate_out: protoc-gen-gotemplate: Plugin failed with status code 1.

From https://github.com/rvolosatovs/docker-protobuf/runs/6016029871

Looks like the binary is missing or not executable, should inspect the resulting image

grpc-java arm64 package is missing in Alpine package repositories https://pkgs.alpinelinux.org/packages?name=grpc-java&branch=edge

See https://github.com/znly/docker-protobuf/issues/25
https://github.com/scalapb/ScalaPB

Summary

Switch to a tagged version of protobuf-c once a successor version of 1.3.1 is released.

Why do we need this?

To use stable software

What is already there? What do you see now?

Using a commit directly, see #11 and #18 for reasoning

What is missing? What do you want to see?

Stable version

How do you propose to implement this?

Change the version in Makefile and add prepend v to the version in Dockerfile

Can you do this yourself and submit a Pull Request?

yes

See https://github.com/znly/docker-protobuf/issues/56
https://github.com/improbable-eng/ts-protoc-gen

Summary

Let's add protoc-gen-gql to the image.

Why do we need this?

Protobuf is a good tool for sharing a specification between developers, so this feature is very helpful when using gRPC and GraphQL together.

What is already there? What do you see now?

https://github.com/danielvladco/go-proto-gql

What is missing? What do you want to see?

https://github.com/danielvladco/go-proto-gql/tree/master/example

How do you propose to implement this?

Add binary into image

Can you do this yourself and submit a Pull Request?

Yes

Summary

Since v3.1.23, when running the image with using protoc-gen-grpc-java, the following errors are shown.

Steps to Reproduce

1. Running image with --plugin=protoc-gen-grpc-java=/usr/bin/protoc-gen-grpc-java

What do you see now?

Error loading shared library libprotoc.so.3.11.2.0: No such file or directory (needed by /usr/bin/protoc-gen-grpc-java)
Error loading shared library libprotobuf.so.3.11.2.0: No such file or directory (needed by /usr/bin/protoc-gen-grpc-java)
Error relocating /usr/bin/protoc-gen-grpc-java: _ZNK6google8protobuf16MethodDescriptor17GetSourceLocationEPNS0_14SourceLocationE: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf8compiler4java9ClassNameB5cxx11EPKNS0_14FileDescriptorE: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZNK6google8protobuf17ServiceDescriptor17GetSourceLocationEPNS0_14SourceLocationE: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf8compiler4java9ClassNameB5cxx11EPKNS0_10DescriptorE: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf2io7Printer7OutdentEv: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf8compiler10PluginMainEiPPcPKNS1_13CodeGeneratorE: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf2io7PrinterC1EPNS1_20ZeroCopyOutputStreamEc: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf2io7Printer6IndentEv: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf2io7PrinterD1Ev: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf8compiler23ParseGeneratorParameterERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPSt6vectorISt4pairIS7_S7_ESaISC_EE: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf8compiler13CodeGeneratorD2Ev: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZNK6google8protobuf16MethodDescriptor11output_typeEv: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZNK6google8protobuf16MethodDescriptor10input_typeEv: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZN6google8protobuf2io7Printer5PrintERKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_St4lessIS9_ESaISt4pairIKS9_S9_EEEPKc: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZNK6google8protobuf8compiler13CodeGenerator11GenerateAllERKSt6vectorIPKNS0_14FileDescriptorESaIS6_EERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS1_16GeneratorContextEPSG_: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZTIN6google8protobuf8compiler13CodeGeneratorE: symbol not found
Error relocating /usr/bin/protoc-gen-grpc-java: _ZTVN6google8protobuf8compiler13CodeGeneratorE: symbol not found
--grpc-java_out: protoc-gen-grpc-java: Plugin failed with status code 127.

What do you want to see instead?

No errors.

Environment

Not related to local environment.

How do you propose to implement this?

Maybe reverting the changes for Image size was reduced in v3.1.23?

ref: #49

Can you do this yourself and submit a Pull Request?

No

Summary

protoc-gen-swift and protoc-gen-grpc-swift doesn't run on Alpine Image based container.
It only runs properly on Ubuntu Image based container

Steps to Reproduce

1. docker run --rm -it --name protoc --entrypoint /bin/sh thethingsindustries/protoc:development
2. protoc-gen-swift --version

What do you see now?

./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libswiftCore.so)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicuucswift.so.65)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicuucswift.so.65)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicuucswift.so.65)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicui18nswift.so.65)
./protoc-gen-grpc-swift: /usr/lib/libstdc++.so.6: no version information available (required by /protoc-gen-swift/libicui18nswift.so.65)
./protoc-gen-grpc-swift: Relink `/usr/lib/libstdc++.so.6' with `/protoc-gen-swift/libm.so.6' for IFUNC symbol `floor'
Segmentation fault (core dumped)

What do you want to see instead?

protoc-gen-swift 1.9.0

Environment

The Things Network Command-line Interface: ttn-lw-cli
Version:             3.12.2
Build date:          2021-04-30T08:48:12Z
Git commit:          3403b3955
Go version:          go1.16.3
OS/Arch:             darwin/amd64

How do you propose to implement this?

The protoc-gen-swift and protoc-gen-grpc-swift works fine on "Ubuntu Image based Container".
It only doesn't work when it is run on alpine image based container. I'm currently not sure what's the fundemental difference between the two containers, but I think that finding that difference should be the key to resolve the issue.

This behavior was introduced by #76 . If you revert the PR, protoc-gen-swift and protoc-gen-grpc-swift would at least work.

Sometimes clients post payloads with incorrect field names. These field values are lost since they do not have designated fields in target structs. Is it possible to have the generated grpc code expose the raw, unadulterated payload bytes in the context object passed to the handlers?

Summary

go mod init should be removed once pseudomuto/protoc-gen-doc@0b08327 lands in a release

Why do we need this?

To make our build process quicker and simpler

What is already there? What do you see now?

go mod init, which converts the dep dependencies to go mod format

What is missing? What do you want to see?

The above statement removed

How do you propose to implement this?

Wait for pseudomuto/protoc-gen-doc@0b08327 to land in a release, update version and remove go mod init

Can you do this yourself and submit a Pull Request?

yes

Summary

Add Kotlin support. Refs TheThingsArchive/api#43

How do you propose to implement this?

Investigate https://github.com/streem/pbandk

Can you do this yourself and submit a Pull Request?

yes

A new version 1.2.0 of gRPC Web is available.

Development of #113 revealed that protoc-gen-ts tests fail when the plugin binary is compressed by the UPX stage. This issue is a marker to investigate why.

Is there an existing issue for this?

• I have searched the existing issues

Description

#128 bumped the protoc version from 3.18 to 3.21.

The JavaScript plugin was moved out to a separate repository in protobuf 3.21 (announcement), so a new protoc-gen-js plugin is now needed to generate JS code. Since this does not yet exist in Alpine (tracking issue here), and the plugin is not yet available in npm like it is for TypeScript, and the released plugin binaries depend on GNU libc instead of musl libc, we need to build the plugin ourself using Bazel.

Bazel 5.2.0+ is required to build, but we cannot build it under Alpine due to this bug. I plan to resolve this with Alpine directly, since we really shouldn't be building Bazel itself if not necessary. Alternatively, we could install libstd++ in the target container, but let's see if any of the other blockers get resolved first.

Acceptance Criteria

Working protoc_gen_js build under Alpine.

Suggestions for a technical implementation

See above

make test fails. When not suppressing output in Makefile:

$ make clean
rm -rf .work dist
find ./testdata -name '*.pb.go' -delete -or -name '*.pb.fm.go' -delete
$ make test
Regenerating golden files...
Running tests...
TMPDIR="/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask/.work/tmp.THv" WORKDIR="/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask/.work/tmp.THv" PROTOC="docker run --user `id -u` --rm --mount type=bind,src=/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask,dst=/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask -e IN_TEST -w /Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask thethingsindustries/protoc:3.0.15" go test -regenerate
--- FAIL: TestGolden (1.25s)
    main_test.go:57: Running 'docker run --user 501 --rm --mount type=bind,src=/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask,dst=/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask -e IN_TEST -w /Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask thethingsindustries/protoc:3.0.15 --plugin=protoc-gen-fieldmask=/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask/.work/tmp.THv/go-build351307003/b001/protoc-gen-fieldmask.test -Ivendor -Itestdata --fieldmask_out=/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask/.work/tmp.THv/fieldmask-test141648980 --gogo_out=/Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask/.work/tmp.THv/fieldmask-test141648980 testdata/testdata.proto'...
    main_test.go:60: Output:
        /Users/johan/dev/go/src/github.com/TheThingsIndustries/protoc-gen-fieldmask/.work/tmp.THv/go-build351307003/b001/protoc-gen-fieldmask.test: program not found or is not executable
        --fieldmask_out: protoc-gen-fieldmask: Plugin failed with status code 1.
    main_test.go:66: Error: exit status 1
FAIL
exit status 1
FAIL	github.com/TheThingsIndustries/protoc-gen-fieldmask	1.260s
make: *** [test] Error 1

#311 0.755 qemu-aarch64: Could not open '/lib/ld-linux-aarch64.so.1': No such file or directory
#311 0.765 --dart_out: protoc-gen-dart: Plugin failed with status code 255.

from https://github.com/rvolosatovs/docker-protobuf/runs/6016037841

Probably should either:
a. get Alpine aarch ld.so from somewhere
b. patchelf to link to a different one?

on amd64:

/ # ldd /usr/bin/protoc-gen-dart
	/lib64/ld-linux-x86-64.so.2 (0x7f3c36623000)
	libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f3c36623000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f3c36623000)
	libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3c36623000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3c36623000)
	ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7f3c35f65000)
Error relocating /lib/ld-linux-x86-64.so.2: unsupported relocation type 37
Error relocating /usr/bin/protoc-gen-dart: __sbrk: symbol not found

Our build recently started failing with:

> [protoc_gen_scala 5/8] RUN gu install native-image:
0.240 Downloading: Release index file from oca.opensource.oracle.com
2.121 Error: Error reading component list: https://oca.opensource.oracle.com/gds/meta-data.json

This is likely due to the removal of GraalVM Updater from the image we use to build ScalaPB. Native Image should now be included with GraalVM directly, but it doesn't work. I've asked for help here scalapb/ScalaPB#1580

Swift is excluded from arm64 builds currently. See #87 for more details

Possibly related #77

Hey,

we had a few issues with the protobuf docker image for the new M1 macbooks. Currently the Alpine version is still 3.15 which comes with qemu (6.1) out of the box. The full support for the new M1 systems unfortunately is only done with version 6.2 of qemu.
It would solve a lot of problems for us to bump the alpine version to 3.16 especially if it would be done in the upcoming release of v.4.0 of the docker image.

If you have any questions feel free to drop them & thanks :)

Update to gRPC-Web 1.0.4, which fixes a lot of bugs for code generation.

Summary

Add support for generating Dart files from proto definitions.

Why do we need this?

Dart is one of the officially supported languages for Protocol Buffers and gRPC. With the current rise of Flutter, Dart's usage will increase. I have a project that will use Dart for the client-end and Go for the backend, and the current image supports the latter but not the former.

What is already there? What do you see now?

N/A

What is missing? What do you want to see?

The Dart protoc plugin

Environment

N/A

How do you propose to implement this?

Perhaps this could help znly/docker-protobuf#32

Can you do this yourself and submit a Pull Request?

I could give it a shot, but I already have too much on my plate.

Summary

...

Why do we need this?

...

What is already there? What do you see now?

...

What is missing? What do you want to see?

...

Environment

...

How do you propose to implement this?

...

Can you do this yourself and submit a Pull Request?

...

Summary:

Add support for https://github.com/lyft/protoc-gen-validate

Why do we need this?

TheThingsNetwork/lorawan-stack#98

What is already there? What do you see now?

No https://github.com/lyft/protoc-gen-validate

What is missing? What do you want to see?

https://github.com/lyft/protoc-gen-validate

How do you propose to implement this?

Add it in a similar fashion as other plugins
Possibly reuse https://github.com/znly/docker-protobuf/pull/54

Summary

It would be great if package updates could be automated

Why do we need this?

To reduce maintenance resources required

What is already there? What do you see now?

Manual update PRs like #42
check-versions.go is used for newest version fetching and then the output is manually compared to the contents of build.sh

What is missing? What do you want to see?

Check versions and open automated PRs if packages are out-of-date.

Environment

CI

How do you propose to implement this?

Run a cron job, which would check that latest versions available and open a PR if there are out-of-date packages. Maybe this could be done with Github Actions.

Can you do this yourself and submit a Pull Request?

yes

Runtimes are missing in latest main

Summary

Let's add protoc-gen-hugodata to the image.

Why do we need this?

We added the generated files in TheThingsNetwork/lorawan-stack#1118, but we need to have it in our tooling so that we can keep the generated files up-to-date.

What is already there? What do you see now?

It's not in here, and we have to update by hand.

What is missing? What do you want to see?

Add the protoc-gen-hugodata binary.

How do you propose to implement this?

• Tag a version
• Add it here

Can you do this yourself and submit a Pull Request?

Yes

Summary

I'm unable to compile protos since I got a macbook with an M1.

Steps to Reproduce

I run the following to compile:

docker run --platform linux/amd64 --rm -v ${PWD}:${PWD} -w ${PWD} rvolosatovs/protoc \
 		--proto_path=. \
 		--go_out=./pb/go \
 		--go_opt=paths=source_relative \
 		--go-grpc_out=./pb/go \
 		--go-grpc_opt=paths=source_relative \
 		--grpc-gateway_out=:./pb/go \
 		--grpc-gateway_opt=paths=source_relative \
 		--openapiv2_out=web/swagger \
                 PROTO_FILES

Running without --platform linux/amd64 returns the same error and throws the following warning: WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

What do you see now?

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
--go_out: protoc-gen-go: Plugin killed by signal 11.
make: *** [protoc] Error 1

What do you want to see instead?

The protos being compiled.

Environment

MacBook Pro (13-inch, M1, 2020)
Apple M1
macOS Big Sur 11.6

How do you propose to implement this?

Adding an arm image would fix this I think.

Can you do this yourself and submit a Pull Request?

No idea if it is easy to port the dockerfile to also work in arm64