[docs] Add applies_to to more situations in exported fields#45654
[docs] Add applies_to to more situations in exported fields#45654colleenmcginnis wants to merge 20 commits intoelastic:mainfrom
applies_to to more situations in exported fields#45654Conversation
botelastic
bot
added
needs_team
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
This comment was marked as outdated.
This comment was marked as outdated.
colleenmcginnis
added
backport-9.0
|
👋 @VihasMakwana I haven't been able to get the check-docs to pass. Any tips? |
|
@colleenmcginnis Hi! |
|
@colleenmcginnis Can you go to |
|
I think you have to same in |
I went through and ran |
|
👋 @elastic/observablt-ci, @rdner, and @elastic/obs-infraobs-integrations (maybe @tommyers-elastic since this contains updates related to #44851) can you please take a look at this PR? 🙏 |
|
@colleenmcginnis there are 227 changed files in the diff. I went through ~10 first files and it's all indentation changes. I think it's fair to say that the expectation that someone would review all of the 227 files is quite unrealistic. Could you point us to the files with important changes that need to be reviewed? Ideally all the formatting changes should happen in a separate PR and should not be mixed with any code changes. |
@rdner Hi! I'd say, we should focus on Same applies for any other module. |
|
@VihasMakwana I would still prefer to have code change and formatting changes in 2 separate PRs, it's a lot of noise. |
Sure, I can copy the changes to the
For what it's worth, if you hide whitespace changes in the diff there are 61 files changed (that's what I did to check all the resulting files before requesting a review from the larger group). |
|
Blocked by #45772. |
I'm not familiar with the check but we can still temporary disable the formatting check in #45772 (review) and re-enable it here. |
@rdner do you know who has the power to help with that once we get the final review from the ci team? |
Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry elastic#45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry.
…lastic#45591) * chore: Update snapshot.yml Made with ❤️️ by updatecli * chore: Update snapshot.yml Made with ❤️️ by updatecli * chore: Update snapshot.yml Made with ❤️️ by updatecli * chore: Update snapshot.yml Made with ❤️️ by updatecli * chore: Update snapshot.yml Made with ❤️️ by updatecli * chore: Update snapshot.yml Made with ❤️️ by updatecli --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
rdner
force-pushed
the
applies_to-exported-fields
branch
from
7832ca1 to
d274ece
Compare
|
This pull request is now in conflicts. Could you fix it? 🙏 |
|
Sorry for the mess, I'm closing this in favor of #45772 where we will include the documentation changes as well for the sake of simplicity. It's easier to backport this way. |
5 participants
Note
Starting with v9.0, there is no longer a new documentation set published with every minor release: the same page stays valid over time and shows version-related evolutions. Read more in Write cumulative documentation.
Related to #45436, https://github.com/elastic/docs-content-internal/issues/128
Updates
generate_fields_docs.pyto add moreapplies_tobadges as needed. Currently we're only addingdeprecatedbadges to fields when there's adeprecatedproperty infields.yml. In addition to those, we want to add anapplies_tobadge when:releasespecified (usually included ifbetaorpreview).versionproperty specified as described in [docs] [proof-of concept] Make it possible to addapplies_tolabels to generated docs #45436. This allows contributors to include version information over time for fields or groups of fields. For example, for a field that was added in beta in 9.0.0 and then went GA in 9.1.0, you would add:To test out the new
versionproperty, I added aversiontofields.ymlfiles that contained new fields in 9.1.0 from these two PRs:I also made some slight formatting changes to improve how definition lists are rendered (indenting all lines in a definition list item).
Some notes for the reviewers: