Integrate BACKBEAT SDK and resolve KACHING license validation
Major integrations and fixes: - Added BACKBEAT SDK integration for P2P operation timing - Implemented beat-aware status tracking for distributed operations - Added Docker secrets support for secure license management - Resolved KACHING license validation via HTTPS/TLS - Updated docker-compose configuration for clean stack deployment - Disabled rollback policies to prevent deployment failures - Added license credential storage (CHORUS-DEV-MULTI-001) Technical improvements: - BACKBEAT P2P operation tracking with phase management - Enhanced configuration system with file-based secrets - Improved error handling for license validation - Clean separation of KACHING and CHORUS deployment stacks 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
anthonyrawlins
291
vendor/go.uber.org/fx/CONTRIBUTING.md
generated
vendored
Normal file
291
vendor/go.uber.org/fx/CONTRIBUTING.md
generated
vendored
Normal file
@@ -0,0 +1,291 @@
|
||||
---
|
||||
sidebarDepth: 2
|
||||
search: false
|
||||
---
|
||||
|
||||
# Contributing
|
||||
|
||||
Thanks for helping to make Fx better for everyone!
|
||||
|
||||
If you'd like to add new exported APIs,
|
||||
please [open an issue](https://github.com/uber-go/fx/issues/new)
|
||||
describing your proposal.
|
||||
Discussing API changes ahead of time makes pull request review much smoother.
|
||||
|
||||
::: tip
|
||||
You'll need to sign [Uber's CLA](https://cla-assistant.io/uber-go/fx)
|
||||
before we can accept any of your contributions.
|
||||
If necessary, a bot will remind
|
||||
you to accept the CLA when you open your pull request.
|
||||
:::
|
||||
|
||||
## Contribute code
|
||||
|
||||
Set up your local development environment to contribute to Fx.
|
||||
|
||||
1. [Fork](https://github.com/uber-go/fx/fork), then clone the repository.
|
||||
|
||||
<code-group>
|
||||
<code-block title="Git">
|
||||
```bash
|
||||
git clone https://github.com/your_github_username/fx.git
|
||||
cd fx
|
||||
git remote add upstream https://github.com/uber-go/fx.git
|
||||
git fetch upstream
|
||||
```
|
||||
</code-block>
|
||||
|
||||
<code-block title="GitHub CLI">
|
||||
```bash
|
||||
gh repo fork --clone uber-go/fx
|
||||
```
|
||||
</code-block>
|
||||
</code-group>
|
||||
|
||||
2. Install Fx's dependencies:
|
||||
|
||||
```bash
|
||||
go mod download
|
||||
```
|
||||
|
||||
3. Verify that tests and other checks pass locally.
|
||||
|
||||
```bash
|
||||
make lint
|
||||
make test
|
||||
```
|
||||
|
||||
Note that for `make lint` to work,
|
||||
you must be using the latest stable version of Go.
|
||||
If you're on an older version, you can still contribute your change,
|
||||
but we may discover style violations when you open the pull request.
|
||||
|
||||
Next, make your changes.
|
||||
|
||||
1. Create a new feature branch.
|
||||
|
||||
```bash
|
||||
git checkout master
|
||||
git pull
|
||||
git checkout -b cool_new_feature
|
||||
```
|
||||
|
||||
2. Make your changes, and verify that all tests and lints still pass.
|
||||
|
||||
```bash
|
||||
$EDITOR app.go
|
||||
make lint
|
||||
make test
|
||||
```
|
||||
|
||||
3. When you're satisfied with the change,
|
||||
push it to your fork and make a pull request.
|
||||
|
||||
<code-group>
|
||||
<code-block title="Git">
|
||||
```bash
|
||||
git push origin cool_new_feature
|
||||
# Open a PR at https://github.com/uber-go/fx/compare
|
||||
```
|
||||
</code-block>
|
||||
|
||||
<code-block title="GitHub CLI">
|
||||
```bash
|
||||
gh pr create
|
||||
```
|
||||
</code-block>
|
||||
</code-group>
|
||||
|
||||
At this point, you're waiting on us to review your changes.
|
||||
We *try* to respond to issues and pull requests within a few business days,
|
||||
and we may suggest some improvements or alternatives.
|
||||
Once your changes are approved, one of the project maintainers will merge them.
|
||||
|
||||
The review process will go more smoothly if you:
|
||||
|
||||
- add tests for new functionality
|
||||
- write a [good commit message](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
|
||||
- maintain backward compatibility
|
||||
- follow our [style guide](https://github.com/uber-go/guide/blob/master/style.md)
|
||||
|
||||
## Contribute documentation
|
||||
|
||||
To contribute documentation to Fx,
|
||||
|
||||
1. Set up your local development environment
|
||||
as you would to [contribute code](#contribute-code).
|
||||
|
||||
2. Install the documentation website dependencies.
|
||||
|
||||
```bash
|
||||
cd docs
|
||||
yarn install
|
||||
```
|
||||
|
||||
3. Run the development server.
|
||||
|
||||
```bash
|
||||
yarn dev
|
||||
```
|
||||
|
||||
4. Make your changes.
|
||||
|
||||
Documentation changes should adhere to the guidance laid out below.
|
||||
|
||||
### Document by purpose
|
||||
|
||||
Documentation is organized in one of the following categories.
|
||||
|
||||
- **Tutorials**: These hold step-by-step instructions for an end-to-end project
|
||||
that a beginner could follow along to.
|
||||
Don't spend time explaining things.
|
||||
If explanations are available elsewhere, link to them.
|
||||
These are entry points to answer the prompt,
|
||||
"I don't know what Fx is, show me what it can do,"
|
||||
so there won't be too many of these.
|
||||
- **Explanations**: These hold long-form explanations of concepts and ideas.
|
||||
These are intended to build an understanding of Fx.
|
||||
Feel free to go wild here--use learning aids like diagrams, tables, etc.
|
||||
- **How-tos**: These are step-by-step instructions for a *specific problem*.
|
||||
Unlike tutorials, these are not meant to be end-to-end.
|
||||
Feel free to leave things out, make assumptions,
|
||||
or provide options ("if you're doing this, do this").
|
||||
As with tutorials, don't spend time explaining;
|
||||
link to explanations elsewhere.
|
||||
|
||||
As an example,
|
||||
|
||||
- A tutorial will use lifecycle hooks as part of
|
||||
a larger set of instructions for a full end-to-end application.
|
||||
- An explanation will explain what lifecycle hooks are, how they work,
|
||||
when and how you should use them, and link to relevant APIs and guides.
|
||||
- A how-to guide will demonstrate how to use lifecycle hooks
|
||||
with an HTTP server, a gRPC server, etc.
|
||||
|
||||
Explanations and how-to guides are often on the same page,
|
||||
but they should be in distinct sections.
|
||||
|
||||
This separation is inspired by the
|
||||
[Divio documentation system](https://documentation.divio.com/),
|
||||
|
||||
### Formatting
|
||||
|
||||
#### ATX-style headers
|
||||
|
||||
Use ATX-style headers (`#`-prefixed),
|
||||
not Setext-style (underlined with `===` or `---`).
|
||||
|
||||
```markdown
|
||||
Bad header
|
||||
==========
|
||||
|
||||
## Good header
|
||||
```
|
||||
|
||||
#### Semantic Line Breaks
|
||||
|
||||
- **Do not** write overly long lines of text
|
||||
- **Do not** "reflow" Markdown paragraphs
|
||||
- **Do** use [Semantic Line Breaks](https://sembr.org/) to break these lines down
|
||||
|
||||
```markdown
|
||||
This is a bad paragraph because it's really long, all on one line. When I open this in a text editor, I'll have to scroll right.
|
||||
|
||||
This is a bad paragraph because even though it's not all one one line, it adds
|
||||
line breaks when it reaches the line length limit. This means that anytime I
|
||||
change anything in this paragraph, I have to "reflow" it, which will change
|
||||
other lines and make the change I'm making more difficult to review.
|
||||
|
||||
This is a good paragraph. It uses semantic line breaks.
|
||||
I can add words or modify an existing sentence,
|
||||
or even parts of a sentence,
|
||||
easily and without affecting other lines.
|
||||
When I change something, the actual change I made is easy to review.
|
||||
Markdown will reflow this into a "normal" pargraph when rendering.
|
||||
```
|
||||
|
||||
### Test everything
|
||||
|
||||
All code samples in documentation must be buildable and testable.
|
||||
|
||||
To aid in this, we have two tools:
|
||||
|
||||
- [mdox](https://github.com/bwplotka/mdox/)
|
||||
- the `region` shell script
|
||||
|
||||
#### mdox
|
||||
|
||||
mdox is a Markdown file formatter that includes support for
|
||||
running a command and using its output as part of a code block.
|
||||
To use this, declare a regular code block and tag it with `mdoc-exec`.
|
||||
|
||||
```markdown
|
||||
```go mdox-exec='cat foo.go'
|
||||
// ...
|
||||
```
|
||||
|
||||
The contents of the code block will be replaced
|
||||
with the output of the command when you run `make fmt`
|
||||
in the docs directory.
|
||||
`make check` will ensure that the contents are up-to-date.
|
||||
|
||||
The command runs with the working directory set to docs/.
|
||||
Store code samples in ex/ and reference them directly.
|
||||
|
||||
#### region
|
||||
|
||||
The `region` shell script is a command intended to be used with `mdox-exec`.
|
||||
|
||||
```plain mdox-exec='region' mdox-expect-exit-code='1'
|
||||
USAGE: region FILE REGION1 REGION2 ...
|
||||
|
||||
Extracts text from FILE marked by "// region" blocks.
|
||||
```
|
||||
|
||||
For example, given the file:
|
||||
|
||||
```
|
||||
foo
|
||||
// region myregion
|
||||
bar
|
||||
// endregion myregion
|
||||
baz
|
||||
```
|
||||
|
||||
Running `region $FILE myregion` will print:
|
||||
|
||||
```
|
||||
bar
|
||||
```
|
||||
|
||||
The same region name may be used multiple times
|
||||
to pull different snippets from the same file.
|
||||
For example, given the file:
|
||||
|
||||
```go
|
||||
// region provide-foo
|
||||
func main() {
|
||||
fx.New(
|
||||
fx.Provide(
|
||||
NewFoo,
|
||||
// endregion provide-foo
|
||||
NewBar,
|
||||
// region provide-foo
|
||||
),
|
||||
).Run()
|
||||
}
|
||||
|
||||
// endregion provide-foo
|
||||
```
|
||||
|
||||
`region $FILE provide-foo` will print,
|
||||
|
||||
```go
|
||||
func main() {
|
||||
fx.New(
|
||||
fx.Provide(
|
||||
NewFoo,
|
||||
),
|
||||
).Run()
|
||||
}
|
||||
```
|
||||
Reference in New Issue
Block a user