Closed mashhurs closed 11 months ago
This is worth moving forward with, even if I have additional thoughts. Feel free to spin them off as a secondary feature-request.
Ideally, we would test daily against:
- the most recent release in the 8.x series (ā maps to
ELASTIC_STACK_VERSION=8.x SNAPSHOT=false
)- a snapshot of the next release in the 8.x series (ā no current mapping, since
logstash_releases.json
has no entry representing8.x
that has artifacts built from8.11
, which as of this writing is where the next release will come from)- the future release from
main
(š” currently indirectly satisfied byELASTIC_STACK_VERSION=8.x SNAPSHOT=true
, since we maintain outside knowledge that8.12.0-SNAPSHOT
is built frommain
)With these changes, we get improvements, but I think we need to add an entry to the upstream
logstash_releases.json
to get what we are looking for.I'm expressing in YAML because I need comments and clean diffs, but the source file of course is actually JSON.
As-implemented now,
snapshots[8.x]
points to an artifact built off of themain
branch; once a feature branch is cut, we no longer point to it.snapshots[8.x]
should be renamed tosnapshots[main]
, and we should introduce a newsnapshots[8.x]
that points to a snapshot built off the latest 8.x branch:snapshots: "7.x": "7.17.16-SNAPSHOT" # next release in 7.x series - "8.x": "8.12.0-SNAPSHOT" # future minor (pre-ff) + "8.x": "8.11.2-SNAPSHOT" # next release in 8.x series + "main": "8.12.0-SNAPSHOT" # future minor (pre-ff)
When 8.12 feature-freezes, the diff of that FF would look like:
snapshots: "7.x": "7.17.16-SNAPSHOT" # next release - "8.x": "8.11.2-SNAPSHOT" # next release in 8.x series + "8.x": "8.12.0-SNAPSHOT" # next release in 8.x series - "main": "8.12.0-SNAPSHOT" # future minor (pre-ff) + "main": "8.13.0-SNAPSHOT" # future minor (pre-ff)
When 8.11.2 drops the diff would look like:
releases: "5.x": "5.6.16" "6.x": "6.8.23" "7.x": "7.17.15" # latest minor, latest patch - "8.x": "8.11.1" # latest minor, latest patch + "8.x": "8.11.2" # latest minor, latest patch snapshots: "7.x": "7.17.16-SNAPSHOT" # next release - "8.x": "8.11.2-SNAPSHOT" # next release in 8.x series + "8.x": "8.11.3-SNAPSHOT" # next release in 8.x series "main": "8.12.0-SNAPSHOT" # future minor (pre-ff)
When 8.12.0 drops the diff would look like:
releases: "5.x": "5.6.16" "6.x": "6.8.23" "7.x": "7.17.15" # latest minor, latest patch - "8.x": "8.11.2" # latest minor, latest patch + "8.x": "8.12.0" # latest minor, latest patch snapshots: "7.x": "7.17.16-SNAPSHOT" # next release - "8.x": "8.11.3-SNAPSHOT" # next release in 8.x series + "8.x": "8.12.1-SNAPSHOT" # next release in 8.x series "main": "8.13.0-SNAPSHOT" # future minor (pre-ff)
This would give us the ability we need, to
- test against the latest release
ELASTIC_STACK_VERSION=8.x SNAPSHOT=false
- test against the next release
ELASTIC_STACK_VERSION=8.x SNAPSHOT=true
- test against upcoming changes pre-FF
ELASTIC_STACK_VERSION=main SNAPSHOT=true
This is a wrap up from our offline discussion and the change to logstash_releases.json
introduces main
and updates next minor 8.11
release (current snapshot). Once sorted out, I am planning apply changes to our release process and share with the team.
Note that, if we don't land the logstash_releases.json
changes, current script ONLY covers current 8.11
release and main
. If it lands, I will add 8.11
snapshot definition in the pipeline.
LGTM (provided the Buildkite job becomes green)
To provide more details, the pipeline becomes red actually and it is an expectation. The plugin is not synced with ES main
branch yet, and it is planned.
Given that we need to create a build to test against 8.11, I think we should go ahead and land it as is. The failures on 8.12/main is because of the missing 8.12 ES snapshot. So lets land, and work next week to unblock this bui8ld on main/8.12
Description
Replacing #93 since repo went public, I had to re-open with a new PR.
A plugin build pipeline which builds the plugin on various ES versions including snapshots and main branch to detect the issues earlies.
Tasks considered:
How to test locally?
NOTE: CI is š“ because pipeline names renamed accordingly. This commit temporarily renames the pipeline to make sure changes are š¢
Run
./.ci/docker-setup.sh & ./.ci/docker-run.sh
to test on localPlacing local integration test logs here
ELASTIC_STACK_VERSION=8.11.0, SNAPSHOT=false
ELASTIC_STACK_VERSION=8.x & SNAPSHOT=true, translates to
8.12.0-SNAPSHOT
, equals tomain
branchELASTIC_STACK_VERSION=8.11.2-SNAPSHOT case