The embedded UI in tasksd is now the @hanzo/gui Tamagui build from
~/work/hanzo/gui/code/admin-tasks/. v1 React/shadcn deleted.
What's still here:
ui/embed.go — Go //go:embed wrapper (handler unchanged)
ui/dist/ — synced from admin-tasks build output
ui/README.md — explains the bundle is built externally
scripts/sync-admin-ui.sh — copies admin-tasks/dist → ui/dist + stamp
Makefile — `ui` target now calls the sync script
Dockerfile — drops the node ui-build stage; expects pre-built
dist/ in the repo or built upstream via CI
What's deleted (62 files):
ui/{src,public,node_modules}/ entire trees
ui/{package.json, vite.config.ts, tailwind.config.js, postcss.config.js,
tsconfig.json, index.html, PERF.md, .gitignore, pnpm-lock.yaml,
vite.perf2.config.ts, tsconfig.tsbuildinfo}
UI-TAMAGUI-MOVED.md (no longer accurate)
Live bundle (verified curl http://127.0.0.1:7243/):
/_/tasks/ → 200
/_/tasks/assets/index-BKuZ1al1.js → 200, 674,748 bytes
/_/tasks/assets/index-DTXHKKx4.css → 200, 9,104 bytes
/v1/tasks/namespaces → 200
Bundle: 339 KB → 675 KB raw / 104 KB → 199 KB gzip. Larger because
Tamagui ships react-native-web + Tamagui core + theme primitives
that shadcn doesn't. Trade: design-system consistency across all
Hanzo admin UIs (kms, commerce, console, etc.) vs 95 KB gzip.
CI note: .github/workflows/build.yml's docker build needs a pre-step
that checks out hanzo/gui and builds admin-tasks, OR commits ui/dist/
to this repo. Dockerfile fails fast with a clear message until then.
Tag v3.0.0 because this is a meaningful UI architecture change.
Use tagged API 1.62.3 for cloud release purposes. This tag includes the
api-go psuedo-version already in the go.mod.
---------
Co-authored-by: Chris St. Pierre <[email protected]>
## What changed?
Add `fairsim` binary (from #8158) to `.gitignore` and `make clean` and
remove it from the repo. (Don't add it to `make bins` since it's not
generally useful.)
## Why
It accidentally got checked in.
## What changed?
Fixed a bug in the gcloud visibility_archiver.go file and added a new
unit test in visibility_archiver_test.go.
## Why?
There is a bug in the visibility-archiver implementation of the Google
Cloud archiver. All archived workflows are being retrieved and displayed
twice. This change fixes that bug.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [ ] covered by existing tests
- [X] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
No risk since the archiver is completely decoupled from the core
functionality.
## What changed?
Add a new cli tool to run the matching fairness simulator, and some
tests for basic fairness behavior.
## Why?
So users can tell how it will behave for their workloads.
## What changed?
Add new PR check mixed brain that runs
[Omes](https://github.com/temporalio/omes) against PR's server and
latest released server.
## Why?
It's easy to make an incompatible change accidentally. And while we do
have tests to catch these, they don't run on PRs. This causes a
significant delay (and context loss).
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)
Verified last backwards incompatible change would have been caught:
https://github.com/temporalio/temporal/actions/runs/22204203793/job/64224556383#step:10:38
## Potential risks
I'd like to make this a _non-blocking_ check until we think it's stable
enough. (requires admin AFAIK)
---------
Co-authored-by: Hanzo Dev <[email protected]>
## What changed?
1. Tweak on the loop in Makefile target `fmt-gofix` to retry based on
output log.
2. Include `fmt-gofix` in CI.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Integrate Go 1.26's new `go fix` into workflow.
NOTE that the changes caused our linter to fire; a [separate
commit](https://github.com/temporalio/temporal/pull/9337/commits/1b23f787aef370098b35829c4d17dcc06230b4c1)
addresses those.
## Why?
Ensure Go code is standardized/modernized.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Adds and integrates `yamlfmt` (Go-based, by Google).
Anything not annotated was changed by `yamlfmt`.
## Why?
Consistent YAML formatting. Reduce unrelated diffs caused by formatting
in PRs.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What Changed
This PR introduces a new `--config-file` flag (and the
`TEMPORAL_SERVER_CONFIG_FILE_PATH ` environment variable) to remove the
dependency on `dockerize` in the Temporal server Docker image.
When a configuration file is specified using either the CLI flag or the
environment variable, the server will load configuration **only** from
that file.
Users who want templating behavior similar to `dockerize` can enable it
by adding the comment `# enable-template` at the top of the
configuration file.
---
### Key Changes
1. **New `--config-file` flag:**
* Adds a global `--config-file` flag that accepts a path to a single
configuration file (absolute or relative to the project root).
* Can also be set via the `TEMPORAL_SERVER_CONFIG_FILE_PATH `
environment variable.
2. **Deprecated legacy flags:**
* The `--config`, `--env`, and `--zone` flags are now marked as
**deprecated** in CLI help text.
* These flags still work for backward compatibility.
3. **Embedded config template:**
* The `config_template.yaml` file is now embedded in the binary to
support loading configuration from environment variables.
* Templating is supported if the file includes the `# enable-template`
comment at the top.
4. **Templating support:**
* Configuration files can use templating by including `#
enable-template` at the beginning of the YAML file.
---
### Configuration Loading Priority (Highest to Lowest)
1. **`--config-file` specified** → Load that specific file
2. **`--config`, `--env`, or `--zone` specified** → Load from
configuration directory (**deprecated**)
3. **No configuration specified** → Load from embedded template using
environment variables (default)
---
### Expected Behavior
The following examples illustrate how the new configuration loading
logic behaves:
* **Default behavior:**
Running `temporal start` without flags loads configuration from
environment variables only using the embedded template.
* **Using `--config-file`:**
`temporal --config-file=/path/to/config.yaml start` loads configuration
from the specified file path.
* **Using `TEMPORAL_SERVER_CONFIG_FILE_PATH`:**
Setting `TEMPORAL_SERVER_CONFIG_FILE_PATH=/path/to/config.yaml temporal
start` has the same effect as using the flag.
* **Validation and error handling:**
The CLI returns clear error messages when conflicting flags or
environment variables are used, or when a specified file does not exist.
---
## Breaking Change
The default behavior of `temporal start` has changed.
It now loads configuration **from environment variables** instead of
using a default template path.
---------
Co-authored-by: Alex Stanfield <[email protected]>
Co-authored-by: michaely520 <[email protected]>
Co-authored-by: Yichao Yang <[email protected]>
Co-authored-by: David Reiss <[email protected]>
## What changed?
- Add [errortype](https://github.com/fillmore-labs/errortype) linter to
`lint-code` target.
- Fix two bugs that it found.
## Why?
Checking error types with errors.As can be tricky.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [x] covered by existing tests
## What changed?
Remove pinned dependency on modernc.org/sqlite.
## Why?
We added this version override when we experienced some table not found
errors. This happens when sqlite db connections are closed when
transactions fail.
We have TestSQLiteTransactionContextCancellation which passes
consistently for this new version. So we believe this issue should not
happen again.
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Reverts to urlfav/cli v1 as per other tools and uses shared flag aliases
where appropriate for more consistency with the other tools.
Works around Go embed's lack of support for symlinks by hard coding the
path to the index template to use. Adds a test to ensure this doesn't
get out of sync with the latest.
## Why?
Better consistency with other tools and being able to actually find the
index template :)
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Added a protoc plugin to generate client for internal CHASM requests to
the history service.
A CHASM library can now define its own set of gRPC services and register
a handler for those.
I had to modify the history client files to be generic, which broke the
mock generation, so I had to hand code the tests there, which IMHO is
actually nicer than the way they were with mocks.
Also opted out of mock generation for CHASM services, there's just not
enough value there.
**NOTE**: Instead of creating three separate clients, I generated a
single layered client, with a constructor that is DI friendly. There
doesn't seem to be a good enough reason to break this out into separate
clients or make client construction configurable (for now).
**NOTE**: We can also get rid of the genrpcwrappers script eventually
and use the protoc plugin approach for all services, I decided not to do
that here though to reduce scope.
For a preview of the generated file see:
-
https://github.com/bergundy/temporal/blob/3a89614a9097eca9061b5f347c01eda735534bbe/chasm/lib/activity/proto/v1/service.proto
-
https://github.com/bergundy/temporal/blob/3a89614a9097eca9061b5f347c01eda735534bbe/chasm/lib/activity/gen/activitypb/v1/service_client.pb.go
## Why?
Keep all CHASM library functionality contained.
## How did you test it?
- [ ] built
## What changed?
- Revive and update original PR #2977 for Elasticsearch CLI tool
Replaces manual curl invocations with a proper CLI tool that leverages
Temporal's built-in Elasticsearch auth providers and provides better
error handling and logging.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
None, net new.
---
> [!NOTE]
> Introduces `temporal-elasticsearch-tool` for ES schema/index
management and ping, extends ES client APIs, embeds ES schema, and
updates Makefile to use the tool.
>
> - **Tools**:
> - New `temporal-elasticsearch-tool` CLI with commands: `setup-schema`,
`update-schema`, `create-index`, `drop-index`, `ping`; supports AWS auth
and uses embedded schema files.
> - Adds entrypoint `cmd/tools/elasticsearch`, README, and basic tests.
> - **Elasticsearch Client**:
> - Extends `CLIClient` with `ClusterPutSettings`, `IndexPutTemplate`,
`IndexPutMapping`, `Ping` and implements them (v7) using raw requests
where needed; allows custom HTTP client from config (e.g., AWS-signed).
> - **Schema**:
> - Embeds ES v7 cluster settings and index template
(`schema.Embedded...` accessors).
> - **Build/Makefile**:
> - Adds build target and binary cleanup for
`temporal-elasticsearch-tool`; updates `install-schema-es` and
`install-schema-xdc` to use the CLI instead of curl.
> - Includes binary in `.goreleaser.yml`; excludes it in
`.dockerignore`.
>
> <sup>Written by [Cursor
Bugbot]() for commit
b37864809ac95a427e74b2a424852992aac2442b. This will update automatically
on new commits. Configure
[here]().</sup>
## What changed?
Ensure that when running `go-generate`, the local gomock is used.
## Why?
Stop wasting people's time chasing errors due to the wrong binary being
used.
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Added iotamixing linter.
> Checks if iotas are being used in const blocks with other non-iota
declarations.
## Why?
We had a near-incident that was traced back to using iota incorrectly.
## How did you test it?
Ran
```
.bin/golangci-lint-v2.5.0 run --verbose --enable-only=iotamixing --config=.github/.golangci.yml
```
and it passes (after addressing the one issue it found).
## What changed?
~Enforce `temporal/cmd/tools/protogen` to set the PATH to point to the
locally installed tools in `.bin`.~
Enforce `temporal/cmd/tools/protogen` to use locally installed protoc
plugins.
## Why?
Without this, it will use whatever is on the PATH; which might not be
the same as in `.bin`.
## How did you test it?
- [ ] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
Without this change, I get different `.pb.go` files emitted as my global
proto-gen-go is used.
## What changed?
Added a CI step that writes a crash JUnit XML file if the testrunner
doesn't complete.
## Why?
(1) Make the "Summary" helpful again by quickly seeing what went wrong.
(2) Make CodeCov show these crashes.
(3) Make our internal test report show these crashes.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
Example run:
https://github.com/temporalio/temporal/actions/runs/17107215158?pr=8221
<img width="1184" height="1167" alt="image"
src="https://github.com/user-attachments/assets/a1c5445e-4359-450d-83ec-8b7a169c47cd"
/>
## What changed?
Upgrade go to the 1.25.0
## How did you test it?
- [x] built
- [x] run locally and tested manually
~Blocked by #8174~
---------
Signed-off-by: Roman Dmytrenko <[email protected]>
Co-authored-by: Stephan Behnke <[email protected]>
Co-authored-by: Stephan Behnke <[email protected]>
## What changed?
Upgrade golangci-lint to v2
## How did you test it?
- [x] run locally and tested manually
---------
Signed-off-by: Roman Dmytrenko <[email protected]>
## What
- Commit generated scheduler protos.
- Improve `make ensure-no-changes` to detect untracked files.
## Why?
The protos were not generated since the tool was committed in a separate
PR from where the protos were added.
## What changed?
Added support for defining protos in chasm libs.
## Why?
Keep everything local to the library.
## How did you test it?
- [x] built
- [x] run locally and tested manually
## What changed?
Stripped Google Cloud Storage's gRPC dependencies out for builds via the
Makefile.
## Why?
Reduce binary size by 16MB; and reduces build times a little (ie
linking).
**Before**
```
-rwxr-xr-x@ 1 stephan staff 119M Jun 30 11:23 temporal-server
```
**After**
```
-rwxr-xr-x@ 1 stephan staff 103M Jun 30 11:24 temporal-server
```
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
Yes, since there are no end-to-end tests, if anyone started using
`storage.NewGRPCClient` that would fail silently. I added a (crude) test
to catch that.
## What changed?
Explicitly set `CGO_ENABLED` for test-related make targets.
## Why?
Missing `CGO_ENABLED` can negatively affect build times on some systems
(e.g. adds +10s on OSX).
Also, consistency. Build targets already have it set.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
This changes all methods that fail tests on the test logger to
**forcibly** fail it by calling `t.Fatalf`.
It adds the stack trace to the failure message as we'd otherwise have no
information on the _path_ to the failure, which is why we initially used
`panic`
## Why?
While testing a separate project I determined that panics from OSS' test
logger (and the internal one it is based on!) were being caught by our
application code, obscuring issues that should cause tests to fail.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
This may fail more tests than we currently do. This is a Good Thing.
This reverts commit 32b8abf9d9.
## What changed?
Reverts the change to return transient and speculative WFT events.
## Why?
Started seeing new error like this
"history_events: premature end of stream, expectedLastEventID=4424 but
no more events after eventID=4422" in pipelines which was not there
before.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
The effective behavior did not consider an ongoing transition (unlike
effective version) and this caused some tasks getting wrong Directive
and be unwontedly dropped.
Plus some other improvements.
## Why?
above
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
---------
Co-authored-by: Carly de Frondeville <[email protected]>
## What changed?
Refactor: remove yaml config files from functional tests. ndc and xdc
configs are still there and I will do it in following PRs.
## Why?
It is much more convenient to have test configuration in code than in
yaml files.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
<!-- Describe what has changed in this PR -->
Remove license header from every file. Because it is really hard to
follow in this PR here is the summary:
1. License header is removed from all `.go` and `.proto` files
:fireworks::fireworks:🎆.
2. `LICENSE` file in the root directory has only Temporal and Uber
copyrights.
3. 5 other `LICENSE` files added to the packages which have copyrights
different from Temporal and Uber: Datadog, Xargin, "Mat Ryer, Tyler
Bunnell and contributors".
4. `license_file` flag is removed from all code generation tools.
5. `copyright_file` flag is removed from `go:generate mockgen`
directive.
6. All copyright related targets are removed from `Makefile`.
7. Updated Temporal copyright year to 2025 everywhere.
## Why?
<!-- Tell your future self why have you made these changes -->
I double checked with legal department that it is not needed to have
license header in every file. One file per repo is enough. I put all
copyrights to the root `LICENSE` file and removed header from all other
files. Also updated tools and `Makefile`.
## What changed?
- Add `make workflowcheck` and run it in CI checks
- Fix issues in existing system workflows. These fixes should not cause
replay errors, because the ordering of map keys did not change which
Temporal history events were generated, nor does switching from
`time.Now()` to `workflow.Now()`
## Why?
<!-- Tell your future self why have you made these changes -->
## How did you test it?
- Scheduler has replay unit tests that should catch any issues
introduced by these changes
- Worker Deployment also has replay unit tests
- Deployment isn't used by any customers, so the lack of replay tests
doesn't matter
- Replication workflow does not have replay tests, but the only change
there was `time.Now()->workflow.Now()`
## Potential risks
Force replication workflow gets an NDE because `time.Now()` was replaced
with `workflow.Now()`
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
This reverts commit e97c027102.
## Why?
It broke a build action
## How did you test it?
## Potential risks
## Documentation
## Is hotfix candidate?
## What changed?
<!-- Describe what has changed in this PR -->
Remove `temporalio-dashboards` submodule. Checkout and extract the
dashboard from `tar` instead.
## Why?
<!-- Tell your future self why have you made these changes -->
Remove top-level `.gitmodules` file (visually cluttering the top-level
of the repo).
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Moved top-level file `.golangci.yml` into `.github` folder.
## Why?
<!-- Tell your future self why have you made these changes -->
Declutter top-level files/folders.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Added Makefile target `update-dependencies-major`.
It lists all _major_ version upgrades and performs them; compared to
`update-dependencies` which only updates _minor_ versions.
## Why?
<!-- Tell your future self why have you made these changes -->
To assess major version upgrades and perform them, if needed.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Example output:
```
Major version upgrades available:
github.com/golang-jwt/jwt/v4: v4.5.1 [latest v5.2.2]
github.com/sony/gobreaker: v1.0.0 [latest v2.1.0]
github.com/urfave/cli: v1.22.16 [latest v2.27.6]
Update dependencies (major versions only) ...
go get github.com/golang-jwt/jwt/[email protected]
go: added github.com/golang-jwt/jwt/v5 v5.2.2
common/authorization/default_jwt_claim_mapper.go:32:2 github.com/golang-jwt/jwt/v5
common/authorization/default_jwt_claim_mapper_test.go:37:2 github.com/golang-jwt/jwt/v5
common/authorization/default_token_key_provider.go:38:2 github.com/golang-jwt/jwt/v5
common/authorization/token_key_provider.go:32:2 github.com/golang-jwt/jwt/v5
go get github.com/sony/gobreaker/[email protected]
go: added github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f
go: added github.com/go-redsync/redsync/v4 v4.13.0
go: added github.com/hashicorp/errwrap v1.1.0
go: added github.com/hashicorp/go-multierror v1.1.1
go: added github.com/redis/go-redis/v9 v9.7.0
go: added github.com/sony/gobreaker/v2 v2.1.0
common/circuitbreaker/circuitbreaker.go:29:2 github.com/sony/gobreaker/v2
service/history/api/describeworkflow/api.go:33:2 github.com/sony/gobreaker/v2
go get github.com/urfave/cli/[email protected].6
go: upgraded github.com/urfave/cli/v2 v2.27.5 => v2.27.6
tools/cassandra/handler.go:31:2 github.com/urfave/cli/v2
tools/cassandra/main.go:31:2 github.com/urfave/cli/v2
tools/common/schema/handler.go:32:2 github.com/urfave/cli/v2
tools/common/schema/test/setuptest.go:34:2 github.com/urfave/cli/v2
tools/common/schema/test/updatetest.go:35:2 github.com/urfave/cli/v2
tools/sql/handler.go:32:2 github.com/urfave/cli/v2
```
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Remove dependency on grpc/example.
Add "testService" to support existing tests.
This will also be a good example on how to add server.
## Why?
<!-- Tell your future self why have you made these changes -->
We shouldn't depend on it to start with.
We run into problems with that dependency.
Latest version of grpc/examples depends on various aws libraries,
dependency I don't want to have.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Existing tests.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
N/A
## What changed?
<!-- Describe what has changed in this PR -->
Upgraded mockgen.
## Why?
<!-- Tell your future self why have you made these changes -->
Dependency hygiene.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
CI.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Downgrading dependency.
Found the offender via
```
go mod graph | grep observability
google.golang.org/grpc/[email protected] google.golang.org/grpc/gcp/[email protected]
```
The package is used in a single grpc integration test. Could maybe be
removed/replaced, but this works for now.
## Why?
<!-- Tell your future self why have you made these changes -->
Causes errors in IDEs:
```
go mod graph | grep observability
google.golang.org/grpc/[email protected] google.golang.org/grpc/gcp/[email protected]
```
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Ran
```
go list -m -json all
```
successfully.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Moved all packages inside `/internal` to `/common`.
## Why?
<!-- Tell your future self why have you made these changes -->
While the `internal` package provides the benefit of preventing any
external party from depending on them, we find that in practice this has
little benefit.
Our compatibility guarantees do not coverage any APIs in `common`
anyway.
Furthermore, splitting commonly-used packages into two places hinders
discoverability. And adds (albeit minor) mental friction.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Compiler.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
External users could start relying on these packages. But that's their
risk assessment to make. There are no guarantees (just like for any
other package in this repo!) outside of the external APIs.
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Updated most tools installed and run by Makefile.
Other tools will be upgraded in separate PRs.
## Why?
<!-- Tell your future self why have you made these changes -->
Dependency hygiene.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Relying on CI here.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Increased OTEL_BSP_SCHEDULE_DELAY from 0 to 100ms.
## Why?
<!-- Tell your future self why have you made these changes -->
Zero is too aggressive and leads to too much CPU usage.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Fixed code coverage reporting.
## Why?
<!-- Tell your future self why have you made these changes -->
We haven't reported code coverage in over a year.
It stopped working when we moved away from Buildkite.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Checkout https://app.codecov.io/gh/temporalio/temporal
There's no data for main ("master") yet, though, until we merge.
I'll also leave the README coveralls badge there for now.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
zeekay
