setup docker build in cicd

[geekflyer]

No description provided.

[rtso]

Do we usually commit the .vscode folder? Also I was looking for a python auto-formatter but none of them worked, I'll try the ones you've listed in this file.

[ying-w]

I would have preference to format as github action (internal ops uses super-linter) https://github.com/aptos-labs/internal-ops/pull/1102/

I'm also not sure we need to commit .vscode unless we have an opinionated way for others to work using this ide

[geekflyer]

I think the general practice is to only check in select files of the .vscode folder that are useful to repro a specific vs code setup across the team. In this case I'm just checking in the workspace file which sets up the workspace, but otherwise isn't too opinionated. You don't have to open the workspace file btw and then this file is practically being ignored, but I highly recommend it as this will make sure the code completion on python projects works correctly, incl. all the thirdparty dependencies.
Just as an example vscodes github repo itself has checked in some .vscode settings as well: https://github.com/microsoft/vscode/tree/main/.vscode

[geekflyer]

I would have preference to format as github action (internal ops uses super-linter) https://github.com/aptos-labs/internal-ops/pull/1102

Agree. We can introduce sth like that in another PR. super-linter would also just invoke black so this wouldn't really change the VS code settings per-se.

[rtso]

Will this action work for Typescript and Rust builds too?

[geekflyer]

yeah, but you have to add typescript/rust etc. to the matrix configuration once we're ready to build these.

[ying-w]

is it worth switching over to python-slim rather than regular python image? will this be widely distributed?

[geekflyer]

hmm. The dockerhub python guide kinda "highly" recommends to use the default image https://hub.docker.com/_/python unless there are specific circumstances like space constraints etc.
I think this image will be only distributed internally as-is (since this is just building the example code) so for now I wouldn't worry about this too much.

I think if in future we distribute something like this as base image we can revisit this.

[larry-aptos]

also a question to this repo: for community, what's their go-to place for generated code?

1. this repo since we included here
   a. but i would prefer we should have a general repo name like indexer-grpc-ecosystem or indexer-grpc.
2. or is our recommendation is to leave this to community to compile? if we want them to compile, how to manage the protobuf release?
3. or we will create a new repo

[geekflyer]

also a question to this repo: for community, what's their go-to place for generated code?

1. this repo since we included here
   a. but i would prefer we should have a general repo name like indexer-grpc-ecosystem or indexer-grpc.
2. or is our recommendation is to leave this to community to compile? if we want them to compile, how to manage the protobuf release?
3. or we will create a new repo

I think ideally we should actually publish the generated code as client libraries onto the respective registries, such as npm and pypi. Generating and publishing these SDKs can be probably done in aptos-core. cc @rtso

[rtso]

also a question to this repo: for community, what's their go-to place for generated code?

1. this repo since we included here
   a. but i would prefer we should have a general repo name like indexer-grpc-ecosystem or indexer-grpc.
2. or is our recommendation is to leave this to community to compile? if we want them to compile, how to manage the protobuf release?
3. or we will create a new repo

I think ideally we should actually publish the generated code as client libraries onto the respective registries, such as npm and pypi. Generating and publishing these SDKs can be probably done in aptos-core. cc @rtso

That's a good idea and would make dependency management easier too as we continue to upgrade our indexer. We also will need to decide if this should belong in the existing aptos SDK or a new SDK specifically for indexing, which makes more sense once the indexer SDK provides more functionality.

For now when the protobuf gets updated (which should be infrequent), I was thinking we can generate the code and update this repo. I can publish the protobuf commands to do that in aptos-core.