[Stack Monitoring] Remove release field, add preview1 identifier

[matschaffer]

What does this PR do?

Remove release field, add preview1 identifier

This is based on recommendations in elastic/kibana#122973 and elastic/package-spec#225

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

How to test this PR locally

#!/usr/bin/env bash

set -euxo pipefail

(cd packages/elasticsearch && elastic-package build)
(cd packages/kibana && elastic-package build)
(cd packages/logstash && elastic-package build)

elastic-package stack up -v -d --version 8.6.0-SNAPSHOT

• Verify that elasticsearch, kibana & logstash packages are not immediately visible in integrations search
• Click the "available as an Elastic Agent integration" from a logs/metrics package to see the latest version

Note that the label will show "Beta" until elastic/kibana#122973 is addressed.

Related issues

Closes #4107

Screenshots

Filebeat/metricbeat tutorials on integration search

Link on metrics page to agent package

Package with new version

[matschaffer]

Initial attempt is still showing me the 1.0.0 technical preview. Could be that it's sorting higher than 1.0.0-preview1

[elasticmachine]

🚀 Benchmarks report

Package elasticsearch 👍(3) 💚(1) 💔(1)

Expand to view

Data stream	Previous EPS	New EPS	Diff (%)	Result
gc	10526.32	7692.31	-2834.01 (-26.92%)	💔

Package kibana 👍(1) 💚(0) 💔(1)

Expand to view

Data stream	Previous EPS	New EPS	Diff (%)	Result
audit	8849.56	6134.97	-2714.59 (-30.67%)	💔

To see the full report comment with /test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-10-18T05:55:47.585+0000

• Duration: 14 min 18 sec

Test stats 🧪

Test	Results
Failed	0
Passed	82
Skipped	0
Total	82

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (9/9)	💚
Files	100.0% (19/19)	💚 2.759
Classes	100.0% (19/19)	💚 2.759
Methods	78.756% (152/193)	👎 -11.493
Lines	90.414% (830/918)	👎 -1.087
Conditionals	100.0% (0/0)	💚

[matschaffer]

2.0.0-preview1 worked. Trying again after wiping my build directory. We might have to increment the version to get the version with the identifier to appear by default since in semver 1.0.0 would be greater than 1.0.0-(x).

[matschaffer]

@crespocarlos @klacabane do either of you happen to know if this is "safe" with regards to release? I'm hoping main doesn't automatically become available and there's some additional release process, but maybe not?

[miltonhultgren]

I think once you bump the version a release is made, I think that's why we held off with bumping the version until we were ready with all changes.

[matschaffer]

Thanks @miltonhultgren ! Maybe we can save this PR for last, then. I think if we just remove the release label now it'll make it harder to test updates since the old 1.0.0 sorts ahead of 1.0.0-preview1.

[klacabane]

There are currently 3 stages, a commit to the repo will publish to the snapshot stage while staging and production stages needs manual operation (documentation here https://github.com/elastic/package-storage/). Now this model will be deprecated in favor of a v2 approach that only exposes a single stage but I don't have the specifics on when this is supposed to happen

@matschaffer can we bump minor or is 1.0.0 taking precedence over 1.1.0-preview1 ?

[matschaffer]

can we bump minor or is 1.0.0 taking precedence over 1.1.0-preview1 ?

I suspect 1.1.0-preview1 will work. I'll go with that 👍🏻

[matschaffer]

Updated. Given what @klacabane said I'm guessing this is okay to merge now and we'll do the manual release process once we've confirmed all the functionality is working as expected.

[matschaffer]

Interesting. Looks like merging this caused the following PRs to get opened:

• [snapshot] Update "logstash" package to version 2.1.0-preview1 package-storage#5913
• [snapshot] Update "elasticsearch" package to version 1.1.0-preview1 package-storage#5914
• [snapshot] Update "kibana" package to version 2.1.0-preview1 package-storage#5915

I'm inclined to go ahead with merge and "release" since the packages have been working in our tests so far, though it may be odd to have it launch ahead of 8.5.0.

Either way it's probably unlikely someone would install them by accident since you have to search or click via the metricbeat "integration" card.

What say you folks? Merge the above (and release) or hold?

[matschaffer]

Nevermind, looks like automerge is a thing. I'm pretty sure this is fine given the above.

[klacabane]

PRs target the snapshot stage which is equivalent to dev I think so no customers will see it unless they specifically point to that stage