## What changed?
A couple of trivial changes to `CONTRIBUTING.md`.
## Why?
- Mention `make go-generate` in the instructions for building with API
changes from other repos. This step is required if adding new endpoints,
such as extending `workflowservice.WorkflowServiceClient`.
- Removes reference to the `make copyright` target. The copyright
headers were removed in
https://github.com/temporalio/temporal/pull/7689, which was merged last
year.
## How did you test it?
NA
## Potential risks
None
## What changed?
There is no `start-postgresql` target in Makefile, the target is
`start-postgres` or `start-postgres12` per the Makefile:
https://github.com/temporalio/temporal/blob/main/Makefile#L674-L677.
If reviewers prefer I can use `start-postgres12` directly.
I decided against updating the actual Makefile target in case it's used
somewhere I'm not aware of.
## Why?
Keep documentation up-to-date.
## 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?
- Remove Docker Builds submodule update
- update instructions on updating the go version
## Why?
docker-builds is no longer used to build server docker images for new
releases
## What changed?
Documentation change only. Updated CONTRIBUTING.md to provide more
explicit instructions about dependencies, update create namespace
command to pass the -n option, remind that you need to start optional
dependencies to use the UI, be opinionated about a first sample to try
out after getting the server running.
## Why?
Because these types of guides should aspire to the don't make me think
principle.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
Co-authored-by: Keith Bodin <keith@Keiths-MacBook-Pro.local>
## What changed?
* Remove previously support for `dockerize` syntax. Now we just support
`sprig`
* updated embedded config
## Why?
Simplification
## How did you test it?
- [x] covered by existing tests
- [x] added new unit test(s)
## Potential risks
Existing config templates will need to be updated to use `sprig` only
syntax. Otherwise the server will not be able to read it.
## 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 <chaptersix@users.noreply.github.com>
Co-authored-by: michaely520 <michaely520@users.noreply.github.com>
Co-authored-by: Yichao Yang <yichao@temporal.io>
Co-authored-by: David Reiss <david@temporal.io>
## What changed?
- Reduced log level of failed Nexus requests originating from worker to
debug level.
- Updated CONTRIBUTING.md and testing.md to reflect current status and
to include IDE debugging.
- Added failure source setting to worker in nexus handler when dispatch
context deadline exceeded.
## Why?
- Today we log an error for every request, which pollutes server logs
and is inconsistent with activity and workflow task failures. We don't
want to completely lose visibility into these errors since some of the
errors can originate internally and may be tricky to debug.
- We've missed spots in setting worker failure source in the nexus
handler
- The docs are a bit outdated, and it's also helpful to have IDE
specific debugging instructions.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Ticket
[OSS-4548](https://temporalio.atlassian.net/browse/OSS-4548)
[OSS-4548]:
https://temporalio.atlassian.net/browse/OSS-4548?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
---------
Co-authored-by: Roey Berman <roey.berman@gmail.com>
## What changed?
Remove the utf8validator component and stop building with protolegacy.
## Why?
Let protobuf validate all strings are valid UTF-8 as specified.
## How did you test it?
Will go through normal release validation.
## Potential risks
All rpcs and persisted data containing invalid UTF-8 in strings will be
rejected immediately. We've been monitoring for invalid data in Temporal
Cloud for most of a year now and all the bad data is gone.
## What changed?
<!-- Describe what has changed in this PR -->
Document Workflow Update internals.
## Why?
<!-- Tell your future self why have you made these changes -->
For better visibility on how Workflow Update is implemented.
---------
Co-authored-by: Stephan Behnke <stephanos@users.noreply.github.com>
## What changed?
<!-- Describe what has changed in this PR -->
Fix go version in `CONTRIBUTING.md`.
## Why?
<!-- Tell your future self why have you made these changes -->
Follow up to #6019.
## What changed?
- Remove `proto/api` submodule.
- Adds a new program that's automatically run by the Makefile as
required to output the api protos in binary form, which can be used by
most tools. The command is run by `go run` and uses the same api-go
reference as the rest of the server for the source protos.
- Removed http annotations from internal matchingservice proto.
## Why?
- Ensure that the api-go import (in go.mod) and the proto files imported
by this repo's proto files are always in sync.
- Simplify update process, stop having to mess with submodules.
## How did you test it?
running commands manually a lot
## Potential risks
Importing protos from somewhere other than our api and google well-known
protos may require some updates to the script's import path logic.
## Documentation
updated docs
## What changed?
<!-- Describe what has changed in this PR -->
Create new `testing.md` with test-specific developer guidance.
It's still very short, happy to add anything else now if there is any -
or just grow it over time.
## Why?
<!-- Tell your future self why have you made these changes -->
To document testing patterns and agreements.
## 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?
I removed the makefile targets for installing and updating our CLI,
`tctl`, and our UI as they're no longer used for development.
If you need these, we recommend installing them through other means.
## Why?
These are unused and, in the case of update-cli, insecure.
## What changed?
<!-- Describe what has changed in this PR -->
I reorganized our docs into `docs/{admin,architecture,development}`.
## Why?
<!-- Tell your future self why have you made these changes -->
We discussed this internally, but I believe this is a better
segmentation for the different audiences looking at our docs. I plan on
adding more stuff to docs/admin like metrics and dynamic config docs.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
I'm mainly looking for broken links.
- I went through each markdown file in docs manually.
- I looked through all inspection errors in the IDE.
- I looked at all references to "docs/" or "develop/" in our code.
## 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?
I've upgraded the version of our Go API in order to allow invalid UTF-8
data in our proto strings.
Please review
5cf979058d
only
## Why?
The version of gogo/protobuf we used allowed invalid UTF-8 in strings
which is a violation of the proto3 spec. We were unaware of this until
our new google/protobuf based structs began failing to deserialize data
we'd used previously
## How did you test it?
I added a new end-to-end test to verify that we can create, describe,
and delete a namespace that contains invalid UTF-8 in multiple
attributes
## Potential risks
This is lower risk than commits prior to this as temporal DBs may
already contain invalid UTF-8 data
## Documentation
I adjusted our docs to mention this behavior and the `protolegacy` tag
## Is hotfix candidate?
Yes: this will be going out as part of our 1.23.0 release. In fact, the
release is blocked on it!
---------
Co-authored-by: David Reiss <david@temporal.io>
## What changed?
<!-- Describe what has changed in this PR -->
Remove support for Cassandra as visibility store.
Updated integration tests that used Cassandra visibility to use
Elasticsearch.
## Why?
<!-- Tell your future self why have you made these changes -->
Deprecating Cassandra visibility.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Updated tests.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No.
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
No.
## What changed?
<!-- Describe what has changed in this PR -->
Switch from `docker-compose` to `docker compose`.
## Why?
<!-- Tell your future self why have you made these changes -->
`docker-compose` was deprecated some time ago.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Run locally.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No risks.
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
No.
<!-- Describe what has changed in this PR -->
**What changed?**
Replace tctl with cli in CONTRIBUTING.md
Create update-cli Make target
<!-- Tell your future self why have you made these changes -->
**Why?**
We're deprecating tctl in v1.22
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
tested the update-cli make target
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
Nothing
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
No
* Bump base image (temporalio/base-ci-builder) version to 1.7.0
* Run gofmt & goimports
* Bump go.mod go directive to 1.19
* Bump go version for goreleaser workflow
Implements the foundation of the proposal here: temporalio/proposals#54
Implements the API itself. Fetching and updating the version graph. Dispatching tasks to new queues according to those versions is not yet implemented.
* Adding temporal-cla and update link
Signed-off-by: Tihomir Surdilovic <tihomir@temporal.io>
* updating quotes and moved cla to docs dir
Signed-off-by: Tihomir Surdilovic <tihomir@temporal.io>
* Rename IDL files to move then under temporalio/temporal
* Rename ProjectRoot in makefile represent new repository
* Update go.mod to represent new repository
* Update all imports to temporalio/temporal package
* Fix tests to work after renaming
