spineeventengine / chat-bot Goto Github PK

Consider implementing a retry/backoff policy for direct HTTP API calls or maybe migrating to Google HTTP client that already has backoff out of the box.

_Originally posted by @armiol in #1 (comment)

Currently, only Travis CI API is supported by the ChatBot. While we're migrating our CI builds to GitHub Actions it should be a good idea to add a way to monitor Actions builds as well.

Cloud Run provides logs gathered from the System.out and System.err out of the box, but the logs are treated by the Stackdriver as plain text messages.

In order to improve the debug and maintenance capabilities, we need to configure Structured logging. The structured (JSON) logs are ingested by the Stackdriving giving us better filtering and searching functionality. E.g. one can find logs by the severity level or for some specific logger using the structured logging.

Cloud Build uses GitHub token to access GitHub packages inside builds. See config.

The token is configured as GCP secret and can be easily updated from the GCP secret manager console.

The current token should be changed from my personal token to someone else's, or even better to a token of a "machine user".

We should reconsider how we treat canceled builds while the cancellation is an intentional action from one of the core developers.

Let's have a different icon for the canceled builds and not treat them as failed ones anymore.

We discussed this matter with @armiol. We'd probably have extension to the System Context which would log commands automatically at the specified level.

For now, I would suggest placing the logging into the place which handles the command, not the one which generates it.

Originally posted by @alexander-yevsyukov in #1

As mentioned, it would be great to have separate command posting/creation logging available as an extension to the framework and we should consider either implementing the extension or moving towards the extension as soon as it is available as part of the framework instead of relying on our custom logs.

As we've seen with the Bootstrap repo, the bot is currently sending notification messages to different threads.

As per our initial requirements, the bot should send messages about the same repo to the same thread.

We have the dead-incoming-bot-messages topic configured for the main incoming-bot-messages as the dead-lettering topic.
Having a message in a dead-incoming-bot-messages topic actually means that the bot is dead and is not able to handle incoming messages.
We should consider creating an alerting policy that'll notify the team when messages could not be delivered.

While the service is not used outside of the deployed environment we should consider reconfiguring the deployment in order to allow only internal GCP access to the endpoints.
With such a config we'll eliminate a chance of accessing the service buy non-authorized parties.

While we're using Kotlin DSL pre-compiled plugins, we currently have bootstrap version declared in one place and gcloud version declared in the other.
We're actually facing a chicken and an egg issue here, cause we're compiling deps.kt using buildsrc/build.gradle.kts and thus are not able to use versions from deps.kt in the build script.
Also, in order to be able to configure plugins inside pre-compiled script plugins such as java-convention.gradle.kts, we must declare all the dependent plugins inside the build.gradle.kts.

Maybe there could be some way to extract Spine versions into a separate .properties file and read its content from both build.gradle.kts and deps.kt in order to have the same source of versions for both. An easy approach to extract smth like version.gradle.kts as we have in the main repo does not work, we're not able to propagate things from extra to deps.kt.

We have to document the cloud environment the ChatBot can be deployed in.

The current version of the application uses local delivery in both Production and Tests.

In order to be able to scale the app properly in the cloud environment, we should consider implementing a distributed delivery strategy and shard observer based on some queueing mechanism, e.g. PubSub or Cloud Tasks.

It is a good idea to use some infrastructure-as-code approach for the deployment. Such an approach makes it easier to do multi-environment deployments as well as eases the management of the deployment.
Maybe terraform or deployment manager could be used here.

Why are we having only one module in this project? From the Java code I see client and server. Aren't they are modules?

Please arrange a project module for each Bounded Context.

Originally posted by @alexander-yevsyukov in #1

It is a good idea to split our single Gradle module into sub-modules with a well-defined separation. As mentioned, it may be a good idea to have separate modules for each Bounded Context, but we should consider talking it through and defining a correct policy for such modules separation in order to be able to reuse the same concept.