-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[packaging][beats-tester] use commit id binaries #22027
Conversation
/packaging |
…ter-commit * upstream/master: feat: package aliases for snapshots (elastic#21960) [DOC] Add firewall as possible troubleshooting issue (elastic#21743) [Filebeat] Add max_number_of_messages config parameter for S3 input (elastic#21993) [Elastic Agent] Fix missing elastic_agent event data (elastic#21994) Document auditbeat system process module config (elastic#21766) Update links (elastic#22012)
/packaging |
1 similar comment
/packaging |
/package |
…ter-commit * upstream/master: [Ingest Manager] Use ML_SYSTEM to detect if agent is running as a service (elastic#21884) Prevent log input from sending duplicate messages due to file renaming (elastic#21911)
Pinging @elastic/integrations-services (Team:Services) |
gitCheckout(basedir: "${BASE_DIR}", branch: props.COMMIT) | ||
} catch(err) { | ||
// Fallback to the head of the branch as used to be. | ||
gitCheckout(basedir: "${BASE_DIR}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in case of error getting the artifact the build will continue, Is that correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, just wanted to keep the backward compatibility with the existing behaviour, which it's not ideal, but just in case something bad happens when fetching the artifacts from the upstream build, at least the behaviour will remain working
💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
Co-authored-by: cachedout <mike.place@elastic.co>
Jenkins run the tests please |
/package |
* upstream/master: [JJBB] Add 6.8+ branches (elastic#22321) [CI] Support Windows-8 (elastic#22307) Change cloud.provider from googlecloud to gcp in billing metricset (elastic#22287) [packaging][beats-tester] use commit id binaries (elastic#22027) [CI] Report error in the catch section (elastic#22297)
* upstream/master: [JJBB] Add 6.8+ branches (elastic#22321) [CI] Support Windows-8 (elastic#22307) Change cloud.provider from googlecloud to gcp in billing metricset (elastic#22287) [packaging][beats-tester] use commit id binaries (elastic#22027) [CI] Report error in the catch section (elastic#22297)
# Conflicts: # .ci/packaging.groovy # Jenkinsfile
What does this PR do?
#21903 in place therefore let's consume those artifacts/binaries, for such, the parentstream will store their build data to be consumed by the downstream jobs.
More context
Packaging
/packaging
comment, therefore it will use the latest commit.Beats tester
Beats tester pipeline that has been triggered by the packaging pipeline then the commit id used for the packaging will be the one used for.
Why is it important?
Avoid known issues when the beats-tester and end2end pipelines consume artifacts that don't match with the upstream build that caused the package generation.
Related issues
Relates #21903
Blocked by elastic/beats-tester#185
Tests
packaging.properties
is generated to be consumed by thepackaging
pipeline ->beats-tester.properties
is generated to be consumed by thebeats-tester
packaging
->beats-tester