* Exit with code 1 when the check script fails (#2022)
* Optimize script logs
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Exit with code 1 when the check script fails
* cicd: bump League Patch (#2025)
* Execute after the component check succeeds && minio.Enable is not configured to use MinIO (#2026)
* Exit with code 1 when the check script fails
* Exit with code 1 when the check script fails
* Exit with code 1 when the check script fails
* Exit with code 1 when the check script fails
* Handle the return value of pre-start
* Handle the return value of pre-start
* Handle the return value of pre-start
* minio.Enable is not configured to use MinIO, therefore the image server is not checked
* minio.Enable is not configured to use MinIO, therefore the image server is not checked
* minio.Enable is not configured to use MinIO, therefore the image server is not checked
* minio.Enable is not configured to use MinIO, therefore the image server is not checked
* Log redirection causes incorrect program exit status.
---------
Co-authored-by: OpenIM Bot <124379614+kubbot@users.noreply.github.com>
* Exit with code 1 when the check script fails (#2022)
* Optimize script logs
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Optimizing Docker Log Output Detection
* Exit with code 1 when the check script fails
* Exit with code 1 when the check script fails
* Exit with code 1 when the check script fails
* Exit with code 1 when the check script fails
* Exit with code 1 when the check script fails
* Handle the return value of pre-start
* Handle the return value of pre-start
* Handle the return value of pre-start
* minio.Enable is not configured to use MinIO, therefore the image server is not checked
* minio.Enable is not configured to use MinIO, therefore the image server is not checked
* minio.Enable is not configured to use MinIO, therefore the image server is not checked
* minio.Enable is not configured to use MinIO, therefore the image server is not checked
OpenIM, an intricate project, requires a robust logging mechanism to diagnose issues, maintain system health, and provide insights. A custom-built logging system embedded within OpenIM ensures consistent and structured logs. Let's delve into the design of this logging system and understand its various functions and their usage scenarios.
- When specifying ranges of numbers, use inclusive ranges whenever possible.
- Go 1.13 or above is recommended, and the error generation method is `fmt.Errorf("module xxx: %w", err)`.
### 1.4 Panic Processing
The use of `panic` should be carefully controlled in Go applications to ensure program stability and predictable error handling. Following are revised guidelines emphasizing the restriction on using `panic` and promoting alternative strategies for error handling and program termination.
- **Prohibited in Business Logic:** Using `panic` within business logic processing is strictly prohibited. Business logic should handle errors gracefully and use error returns to propagate issues up the call stack.
- **Restricted Use in Main Package:** In the main package, the use of `panic` should be reserved for situations where the program is entirely inoperable, such as failure to open essential files, inability to connect to the database, or other critical startup issues. Even in these scenarios, prefer using structured error handling to terminate the program.
- **Use `log.Fatal` for Critical Errors:** Instead of panicking, use `log.Fatal` to log critical errors that prevent the program from operating normally. This approach allows the program to terminate while ensuring the error is properly logged for troubleshooting.
- **Prohibition on Exportable Interfaces:** Exportable interfaces must not invoke `panic`. They should handle errors gracefully and return errors as part of their contract.
- **Prefer Errors Over Panic:** It is recommended to use error returns instead of panic to convey errors within a package. This approach promotes error handling that integrates smoothly with Go's error handling idioms.
#### Alternative to Panic: Structured Program Termination
To enforce these guidelines, consider implementing structured functions to terminate the program gracefully in the face of unrecoverable errors, while providing clear error messages. Here are two recommended functions:
```go
// ExitWithError logs an error message and exits the program with a non-zero status.
In this example, `ExitWithError` is used to terminate the program when an unrecoverable error occurs, providing a clear error message to stderr and exiting with a non-zero status. This approach ensures that critical errors are logged and the program exits in a controlled manner, facilitating troubleshooting and maintaining the stability of the application.
### 1.4 panic processing
- Panic is prohibited in business logic processing.
- In the main package, panic is only used when the program is completely inoperable, for example, the file cannot be opened, the database cannot be connected, and the program cannot run normally.
- In the main package, use `log.Fatal` to record errors, so that the program can be terminated by the log, or the exception thrown by the panic can be recorded in the log file, which is convenient for troubleshooting.
- An exportable interface must not panic.
- It is recommended to use error instead of panic to convey errors in the package.
### 1.5 Unit Tests
@@ -487,15 +439,10 @@ var allowGitHook bool
- Local variables should be as short as possible, for example, use buf to refer to buffer, and use i to refer to index.
- The code automatically generated by the code generation tool can exclude this rule (such as the Id in `xxx.pb.go`)
### 2.7 Constant Naming
### 2.7 Constant naming
In Go, constants play a critical role in defining values that do not change throughout the execution of a program. Adhering to best practices in naming constants can significantly improve the readability and maintainability of your code. Here are some guidelines for constant naming:
- **Camel Case Naming:** The name of a constant must follow the camel case notation. The initial letter should be uppercase or lowercase based on the access control requirements. Uppercase indicates that the constant is exported (visible outside the package), while lowercase indicates package-private visibility (visible only within its own package).
- **Enumeration Type Constants:** For constants that represent a set of enumerated values, it's recommended to define a corresponding type first. This approach not only enhances type safety but also improves code readability by clearly indicating the purpose of the enumeration.
**Example:**
- The constant name must follow the camel case, and the initial letter is uppercase or lowercase according to the access control decision.
- If it is a constant of enumeration type, you need to create the corresponding type first:
```go
// Code defines an error code type.
@@ -505,40 +452,11 @@ type Code int
const(
// ErrUnknown - 0: An unknown error occurred.
ErrUnknownCode=iota
// ErrFatal - 1: A fatal error occurred.
// ErrFatal - 1: An fatal error occurred.
ErrFatal
)
```
In the example above, `Code` is defined as a new type based on `int`. The enumerated constants `ErrUnknown` and `ErrFatal` are then defined with explicit comments to indicate their purpose and values. This pattern is particularly useful for grouping related constants and providing additional context.
### Global Variables and Constants Across Packages
- **Use Constants for Global Variables:** When defining variables that are intended to be accessed across packages, prefer using constants to ensure immutability. This practice avoids unintended modifications to the value, which can lead to unpredictable behavior or hard-to-track bugs.
- **Lowercase for Package-Private Usage:** If a global variable or constant is intended for use only within its own package, it should start with a lowercase letter. This clearly signals its limited scope of visibility, adhering to Go's access control mechanism based on naming conventions.
**Guideline:**
- For global constants that need to be accessed across packages, declare them with an uppercase initial letter. This makes them exported, adhering to Go's visibility rules.
- For constants used within the same package, start their names with a lowercase letter to limit their scope to the package.
**Example:**
```go
packageconfig
// MaxConnections - the maximum number of allowed connections. Visible across packages.
constMaxConnectionsint=100
// minIdleTime - the minimum idle time before a connection is considered stale. Only visible within the config package.
constminIdleTimeint=30
```
In this example, `MaxConnections` is a global constant meant to be accessed across packages, hence it starts with an uppercase letter. On the other hand, `minIdleTime` is intended for use only within the `config` package, so it starts with a lowercase letter.
Following these guidelines ensures that your Go code is more readable, maintainable, and consistent with Go's design philosophy and access control mechanisms.
### 2.8 Error naming
- The Error type should be written in the form of FooError.
@@ -555,190 +473,6 @@ type ExitError struct {
varErrFormat=errors.New("unknown format")
```
For non-standard Err naming, CICD will report an error
### 2.9 Handling Errors Properly
In Go, proper error handling is crucial for creating reliable and maintainable applications. It's important to ensure that errors are not ignored or discarded, as this can lead to unpredictable behavior and difficult-to-debug issues. Here are the guidelines and examples regarding the proper handling of errors.
#### Guideline: Do Not Discard Errors
- **Mandatory Error Propagation:** When calling a function that returns an error, the calling function must handle or propagate the error, instead of ignoring it. This approach ensures that errors are not silently ignored, allowing higher-level logic to make informed decisions about error handling.
#### Incorrect Example: Discarding an Error
```go
packagemain
import(
"io/ioutil"
"log"
)
funcReadFileContent(filenamestring)string{
content,_:=ioutil.ReadFile(filename)// Incorrect: Error is ignored
returnstring(content)
}
funcmain(){
content:=ReadFileContent("example.txt")
log.Println(content)
}
```
In this incorrect example, the error returned by `ioutil.ReadFile` is ignored. This can lead to situations where the program continues execution even if the file doesn't exist or cannot be accessed, potentially causing more cryptic errors downstream.
#### Correct Example: Propagating an Error
```go
packagemain
import(
"io/ioutil"
"log"
)
// ReadFileContent attempts to read and return the content of the specified file.
In the correct example, the error returned by `ioutil.ReadFile` is propagated back to the caller. The `main` function then checks the error and terminates the program with an appropriate error message if an error occurred. This approach ensures that errors are handled appropriately, and the program does not proceed with invalid state.
### Best Practices for Error Handling
1.**Always check the error returned by a function.** Do not ignore it.
2.**Propagate errors up the call stack unless they can be handled gracefully at the current level.**
3.**Provide context for errors when propagating them, making it easier to trace the source of the error.** This can be achieved using `fmt.Errorf` with the `%w` verb or dedicated wrapping functions provided by some error handling packages.
4.**Log the error at the point where it is handled or makes the program to terminate, to provide insight into the failure.**
By following these guidelines, you ensure that your Go applications handle errors in a consistent and effective manner, improving their reliability and maintainability.
### 2.10 Using Context with IO or Inter-Process Communication (IPC)
In Go, `context.Context` is a powerful construct for managing deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes. It is particularly important in I/O operations or inter-process communication (IPC), where operations might need to be cancelled or timed out.
#### Guideline: Use Context for IO and IPC
- **Mandatory Use of Context:** When performing I/O operations or inter-process communication, it's crucial to use `context.Context` to manage the lifecycle of these operations. This includes setting deadlines, handling cancellation signals, and passing request-scoped values.
#### Incorrect Example: Ignoring Context in an HTTP Call
```go
packagemain
import(
"io/ioutil"
"net/http"
"log"
)
// FetchData makes an HTTP GET request to the specified URL and returns the response body.
// This function does not use context, making it impossible to cancel the request or set a deadline.
In this incorrect example, the `FetchData` function makes an HTTP GET request without using a `context`. This approach does not allow the request to be cancelled or a timeout to be set, potentially leading to resources being wasted if the server takes too long to respond or if the operation needs to be aborted for any reason.
#### Correct Example: Using Context in an HTTP Call
```go
packagemain
import(
"context"
"io/ioutil"
"net/http"
"log"
"time"
)
// FetchDataWithContext makes an HTTP GET request to the specified URL using the provided context.
// This allows the request to be cancelled or timed out according to the context's deadline.
In the correct example, `FetchDataWithContext` uses a context to make the HTTP GET request. This allows the operation to be cancelled or subjected to a timeout, as dictated by the context passed to it. The `context.WithTimeout` function is used in `main` to create a context that cancels the request if it takes longer than 5 seconds, demonstrating a practical use of context to manage operation lifecycle.
### Best Practices for Using Context
1.**Pass context as the first parameter of a function**, following the convention `func(ctx context.Context, ...)`.
2.**Never ignore the context** provided to you in functions that support it. Always use it in your I/O or IPC operations.
3.**Avoid storing context in a struct**. Contexts are meant to be passed around within the call stack, not stored.
4.**Use context's cancellation and deadline features** to control the lifecycle of blocking operations, especially in network I/O and IPC scenarios.
5.**Propagate context down the call stack** to any function that supports it, ensuring that your application can respond to cancellation signals and deadlines effectively.
By adhering to these guidelines and examples, you can ensure that your Go applications handle I/O and IPC operations more reliably and efficiently, with proper support for cancellation, timeouts, and request-scoped values.
## 3. Comment specification
- Each exportable name must have a comment, which briefly introduces the exported variables, functions, structures, interfaces, etc.
If you wish to view the script's logging documentation, you can click on this link: [Logging Documentation](https://github.com/OpenIMSDK/Open-IM-Server/blob/main/docs/contrib/bash-log.md).
Below is the documentation for logging and error handling in the OpenIM Go project.
To create a standard set of documentation that is quick to read and easy to understand, we will highlight key information about the `Logger` interface and the `CodeError` interface. This includes the purpose of each interface, key methods, and their use cases. This will help developers quickly grasp how to effectively use logging and error handling within the project.
## Logging (`Logger` Interface)
### Purpose
The `Logger` interface aims to provide the OpenIM project with a unified and flexible logging mechanism, supporting structured logging formats for efficient log management and analysis.
### Key Methods
- **Debug, Info, Warn, Error**
Log messages of different levels to suit various logging needs and scenarios. These methods accept a context (`context.Context`), a message (`string`), and key-value pairs (`...interface{}`), allowing the log to carry rich context information.
- **WithValues**
Append key-value pair information to log messages, returning a new `Logger` instance. This helps in adding consistent context information.
- **WithName**
Set the name of the logger, which helps in identifying the source of the logs.
- **WithCallDepth**
Adjust the call stack depth to accurately identify the source of the log message.
### Use Cases
- Developers should choose the appropriate logging level (such as `Debug`, `Info`, `Warn`, `Error`) based on the importance of the information when logging.
- Use `WithValues` and `WithName` to add richer context information to logs, facilitating subsequent tracking and analysis.
## Error Handling (`CodeError` Interface)
### Purpose
The `CodeError` interface is designed to provide a unified mechanism for error handling and wrapping, making error information more detailed and manageable.
### Key Methods
- **Code**
Return the error code to distinguish between different types of errors.
- **Msg**
Return the error message description to display to the user.
- **Detail**
Return detailed information about the error for further debugging by developers.
- **WithDetail**
Add detailed information to the error, returning a new `CodeError` instance.
- **Is**
Determine whether the current error matches a specified error, supporting a flexible error comparison mechanism.
- **Wrap**
Wrap another error with additional message description, facilitating the tracing of the error's cause.
### Use Cases
- When defining errors with specific codes and messages, use error types that implement the `CodeError` interface.
- Use `WithDetail` to add additional context information to errors for more accurate problem localization.
- Use the `Is` method to judge the type of error for conditional branching.
- Use the `Wrap` method to wrap underlying errors while adding more contextual descriptions.
## Logging Standards and Code Examples
In the OpenIM project, we use the unified logging package `github.com/OpenIMSDK/tools/log` for logging to achieve efficient log management and analysis. This logging package supports structured logging formats, making it easier for developers to handle log information.
Example code: Using the `Logger` interface to log at the info level.
```go
funcmain(){
logger:=log.NewLogger().WithName("MyService")
ctx:=context.Background()
logger.Info(ctx,"Service started","port","8080")
}
```
## Error Handling and Code Examples
We use the `github.com/OpenIMSDK/tools/errs` package for unified error handling and wrapping.
### CodeError Interface and Implementation
The error interface is defined as follows:
```go
typeCodeErrorinterface{
Code()int
Msg()string
Detail()string
WithDetail(detailstring)CodeError
Is(errerror,loose...bool)bool
Wrap(msg...string)error
error
}
```
Example code: Creating and using the `CodeError` interface to handle errors.
```go
packagemain
import(
"fmt"
"github.com/OpenIMSDK/tools/errs"
)
funcmain(){
err:=errs.New(404,"Resource not found")
err=err.WithDetail("
More details")
ife,ok:=err.(errs.CodeError);ok{
fmt.Println(e.Code(),e.Msg(),e.Detail())
}
}
```
### Detailed Logging Standards and Code Examples
1.**Print key information at startup**
It is crucial to print entry parameters and key process information at program startup. This helps understand the startup state and configuration of the program.
**Code Example**:
```go
package main
import (
"fmt"
"os"
)
func main() {
fmt.Println("Program startup, version: 1.0.0")
fmt.Printf("Connecting to database: %s\n", os.Getenv("DATABASE_URL"))
}
```
2. **Use `tools/log` and `fmt` for logging**
Logging should be done using a specialized logging library for unified management and formatted log output.
**Code Example**: Logging an info level message with `tools/log`.
```go
package main
import (
"context"
"github.com/OpenIMSDK/tools/log"
)
func main() {
ctx := context.Background()
log.Info(ctx, "Application started successfully")
}
```
3. **Use standard error output for startup failures or critical information**
Critical error messages or program startup failures should be indicated to the user through standard error output.
6. **Handling logs for API RPC calls and non-RPC applications**
For API RPC calls using gRPC, logs at the information level are printed by middleware on the gRPC server side, reducing the need to manually log in each RPC method. For non-RPC applications, it's recommended to manually log key execution paths to track the application's execution flow.
**gRPC Server-Side Logging Middleware:**
In gRPC, `UnaryInterceptor` and `StreamInterceptor` can intercept Unary and Stream type RPC calls, respectively. Here's an example of how to implement a simple Unary RPC logging middleware:
```go
package main
import (
"context"
"google.golang.org/grpc"
"google.golang.org/grpc/codes"
"google.golang.org/grpc/status"
"log"
"time"
)
// unaryServerInterceptor returns a new unary server interceptor that logs each request.
For non-RPC applications, the key is to log at appropriate places in the code to maintain an execution trace. Here's a simple example showing how to log when handling a task:
In both scenarios, appropriate logging can help developers and operators monitor the health of the system, trace the source of issues, and quickly locate and resolve problems. For gRPC logging, using middleware can effectively centralize log management and control. For non-RPC applications, ensuring logs are placed at critical execution points can help understand the program's operational flow and state changes.
### When to Wrap Errors?
1. **Wrap errors generated within the function**
When an error occurs within a function, use `errs.Wrap` to add context information to the original error.
**Code Example**:
```go
func doSomething() error {
// Suppose an error occurs here
err, _ := someFunc()
if err != nil {
return errs.Wrap(err, "doSomething failed")
}
}
```
2. **Wrap errors from system calls or other packages**
When calling external libraries or system functions that return errors, also add context information to wrap the error.
**Code Example**:
```go
func readConfig(file string) error {
_, err := os.ReadFile(file)
if err != nil {
return errs.Wrap(err, "Failed to read config file")
}
return nil
}
```
3. **No need to re-wrap errors for internal module calls**
If an error has been appropriately wrapped with sufficient context information in an internal module call, there's no need to wrap it again.
**Code Example**:
```go
func doSomething() error {
err := doAnotherThing()
if err != nil {
return err
}
return nil
}
```
4. **Ensure comprehensive wrapping of errors with detailed messages**
When wrapping errors, ensure to provide ample context information to make the error more understandable and easier to debug.
**Code Example**:
```go
func connectDatabase() error {
err := db.Connect(config.DatabaseURL)
if err != nil {
return errs.Wrap(err, fmt.Sprintf("Failed to connect to database, URL: %s", config.DatabaseURL))
}
return nil
}
```
## Log Standards
### Log Standards
- The unified log package `github.com/openimsdk/open-im-server/internal/pkg/log` should be used for all logging;
- Use structured logging formats: `log.Infow`, `log.Warnw`, `log.Errorw`, etc. For example: `log.Infow("Update post function called")`;
- All logs should start with an uppercase letter and should not end with a `.`. For example: `log.Infow("Update post function called")`;
- Use past tense. For example, use `Could not delete B` instead of `Cannot delete B`;
- Adhere to log level standards:
- Debug level logs use `log.Debugw`;
- Info level logs use `log.Infow`;
- Warning level logs use `log.Warnw`;
- Error level logs use `log.Errorw`;
- Panic level logs use `log.Panicw`;
- Fatal level logs use `log.Fatalw`.
- Log settings:
- Development and test environments: The log level is set to `debug`, the log format can be set to `console` / `json` as needed, and caller is enabled;
- Production environment: The log level is set to `info`, the log format is set to `json`, and caller is enabled. (**Note**: In the early stages of going online, to facilitate troubleshooting, the log level can be set to `debug`)
- When logging, avoid outputting sensitive information, such as passwords, keys, etc.
- If you are calling a logging function in a function/method with a `context.Context` parameter, it is recommended to use `log.L(ctx).Infow()` for logging.
@@ -96,6 +96,7 @@ We reinforce our approach to branch management and versioning with stringent tes
This document describes the maximum version skew supported between various openim components. Specific cluster deployment tools may place additional restrictions on version skew.
### Supported version skew
In highly-available (HA) clusters, the newest and oldest `openim-api` instances must be within one minor version.
@@ -209,7 +210,6 @@ git merge release-v3.1
# Push the updates to the main branch
git push origin main
```
## Release Process
```
@@ -232,7 +232,5 @@ For more details on managing Docker image versions, visit [OpenIM Docker Images
More on multi-branch version management design and version management design at helm charts：
About Helm's version management strategy for Multiple Apps and multiple Services:
# OpenIM Typecheck: Cross-Platform Source Code Type Checking for Go
## Introduction
OpenIM Typecheck is a robust tool designed for cross-platform source code type checking across all Go build platforms. This utility leverages Go’s built-in parsing and type-check libraries (`go/parser` and `go/types`) to deliver efficient and reliable code analysis.
## Advantages
- **Speed**: A complete compilation with OpenIM can take approximately 3 minutes. In contrast, OpenIM Typecheck achieves this in mere seconds, significantly enhancing productivity.
- **Resource Efficiency**: Unlike the typical requirement of over 40GB of RAM for standard processes, Typecheck operates effectively with less than 8GB of RAM. This reduction in resource consumption makes it highly suitable for a variety of systems, reducing overheads and facilitating smoother operations.
## Implementation
OpenIM Typecheck employs Go's native parsing and type-checking libraries (`go/parser` and `go/types`). However, it's important to note that these libraries aren't identical to those used by the Go compiler. While occasional mismatches may occur, these libraries generally provide close approximations to the compiler's functionality, offering a reliable basis for type checking.
## Error Handling
Typecheck's approach to error handling is pragmatic, focusing on practicality and build continuity.
**Errors reported by `go/types` but not by `go build`**:
- **Actual Errors** (as per the specification):
- These should ideally be rectified. If rectification is not feasible, such as in cases of ongoing work or external dependencies in the code, these errors can be overlooked.
- Example: Unused variables within a closure.
- **False Positives**:
- These errors should be ignored and, where appropriate, reported upstream for resolution.
- Example: Type mismatches between staging and generated types.
**Errors reported by `go build` but not by us**:
- CGo-related errors, including both syntax and linker issues, are outside our scope.
## Usage
### Locally
To run Typecheck locally, simply use the following command:
```bash
make verify
```
### Continuous Integration (CI)
In CI environments, Typecheck can be integrated into the workflow as follows:
```yaml
- name: Typecheck
run: make verify
```
This streamlined process facilitates efficient error detection and resolution, ensuring a robust and reliable build pipeline.
More to learn about typecheck [share blog](https://nsddd.top/posts/concurrent-type-checking-and-cross-platform-development-in-go/)
serial=flag.Bool("serial",false,"don't type check platforms in parallel (equivalent to --parallel=1)")
parallel=flag.Int("parallel",2,"limits how many platforms can be checked in parallel. 0 means no limit.")
skipTest=flag.Bool("skip-test",false,"don't type check test code")
tags=flag.String("tags","","comma-separated list of build tags to apply in addition to go's defaults")
ignoreDirs=flag.String("ignore-dirs","","comma-separated list of directories to ignore in addition to the default hardcoded list including staging, vendor, and hidden dirs")
// When processed in order, windows and darwin are early to make
// interesting OS-based errors happen earlier.
crossPlatforms=[]string{
"linux/amd64","windows/386",
"darwin/amd64","darwin/arm64",
"linux/386","linux/arm",
"windows/amd64","linux/arm64",
"linux/ppc64le","linux/s390x",
"windows/arm64",
}
// directories we always ignore
standardIgnoreDirs=[]string{
// Staging code is symlinked from vendor/k8s.io, and uses import
// paths as if it were inside of vendor/. It fails typechecking
// inside of staging/, but works when typechecked as part of vendor/.
"staging",
"components",
"logs",
// OS-specific vendor code tends to be imported by OS-specific
// packages. We recursively typecheck imported vendored packages for
// each OS, but don't typecheck everything for every OS.
"vendor",
"test",
"_output",
"*/mw/rpc_server_interceptor.go",
// Tools we use for maintaining the code base but not necessarily
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Xinwei Xiong