Skip to content

Switch changelog update overwite default to false - #4133

Closed
lcawl wants to merge 1 commit into
changelog-upload-overwritefrom
changelog-upload-overwrite-part2
Closed

lcawl wants to merge 1 commit into
changelog-upload-overwritefrom
changelog-upload-overwrite-part2

Conversation

@lcawl

@lcawl lcawl commented Sep 17, 2026

Copy link
Copy Markdown
Contributor

This PR must be merged after (1) #4075, and (2) elastic/docs-actions#346

Summary

Omitting --overwrite now leaves a different remote object in place and exits non-zero.
This change must occur only after the docs-actions have been updated to include --overwrite so their behaviour is unchanged.

Details

Situation Result
New S3 key Upload, with If-None-Match: *
Same content (ETag match) Skip
Different content, no flag Refuse, warn (--overwrite), exit non-zero
--overwrite Replace (no create-only precondition)
--skip-etag-check Put even on ETag match; implies replace

The CLI maps Overwrite = overwrite || skipEtagCheck. S3UploadOptions and ChangelogUploadArguments default Overwrite to false. Docs and docs/cli-schema.json say the same thing.

Tests cover default refuse, --overwrite replace, skip-etag Put, and new-key If-None-Match: *.

Generative AI disclosure

  1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?
  • Yes
  • No
  1. If you answered "Yes" to the previous question, please specify the tool(s) and model(s) used (e.g., Google Gemini, OpenAI ChatGPT-4, etc.).

Tool(s) and model(s) used: Cursor Grok 4.6


Upload changelog entries or bundle artifacts to S3 or Elasticsearch. The command discovers `.yaml` and `.yml` files in a local directory and uploads only files whose content hash changed since the last run. Changelog entries are uploaded once under `changelog/{org}/{repo}/{branch}/{file}`, keyed by the authoring owner, repository, and branch; bundles are uploaded under `bundle/{product}/{file}`, product-scoped from the bundle YAML.
Upload changelog entries or bundle artifacts to S3 or Elasticsearch.
The command discovers `.yaml` and `.yml` files in a local directory and by default uploads only files whose content hash changed since the last run.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence now overstates default behavior. With this PR, a file whose content differs from an existing remote key is not uploaded by default; it is refused unless --overwrite (or --skip-etag-check) is set.

Could you reword this line to mention both parts of the default behavior: unchanged files are skipped, and changed existing keys are refused unless overwrite is requested?

/// <param name="skipEtagCheck">Upload every discovered file even when its content hash matches the remote object. Use to re-trigger downstream scrubbers without changing file content. Implies --overwrite.</param>
/// <param name="overwrite">Replace remote objects whose content differs. Today upload still replaces those objects even if you omit this flag. Pass it so GitHub Actions keep working after a later release that replaces only when the flag is set.</param>
/// <param name="skipEtagCheck">Upload every discovered file even when its content hash matches the remote object. Each upload emits s3:ObjectCreated, which re-triggers the scrubber Lambda on the private bucket. Default behavior (without this flag) skips unchanged files. Also replaces objects whose content differs, so you do not need --overwrite as well.</param>
/// <param name="overwrite">Replace remote objects whose content differs. Omit this flag to skip replacing those existing objects. Unchanged (ETag match) files and PR-alias markers are still skipped. Use --skip-etag-check to upload those too. When a replacement is refused, the warning includes the existing remote object.</param>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This help text sounds unconditional, but the implementation can’t always include the existing remote object content. When GetObject fails, the warning falls back to a "Could not fetch ..." message.

Can we qualify this wording (for example, "when readable") so CLI help doesn’t promise remote content in every refusal case?

@lcawl

lcawl commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

Reverted to simpler #4136

@lcawl lcawl closed this Sep 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant