-
Notifications
You must be signed in to change notification settings - Fork 83
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
ci: enable upload artifacts #1147
Conversation
This pull request does not have a backport label. Could you fix it @v1v? 🙏
NOTE: |
This pull request is now in conflicts. Could you fix it @v1v? 🙏
|
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.
I've seen certain differences in how Beats and Fleet Server repo store the artifacts:
While Beats uses the following structure:
- 📁 beats
- 📁 commits
- 📁 SHA1
- 📁 the_beat
- 📦 [the_beat]-[version]-SNAPSHOT-[os]-[arch][extension], being [os] optional.
- 📁 the_beat
- 📁 SHA1
- 📁 commits
fleet-server uses the following structure:
- 📁 fleet-server
- 📁 commits
- 📁 SHA1
- 📁: fleet-server-[version]-[os]-[arch], being [os] always present in the folder name.
- 📦 fleet-server[extension]
- 📁: fleet-server-[version]-[os]-[arch], being [os] always present in the folder name.
- 📁 SHA1
- 📁 commits
Is that on purpose? I'd have expected having both follow the same structure, with Beats adding an intermediate dir for the_beat
I'm a bit confused about this question, IIUC, the concern is regarding the intermediate folder, but fleet-server is not a monorepo, so there is no need to include an extra folder. The fleet-server build system produces the output that's copied from, the only transformation done in this particular upload process within the CI is related to the Is the issue related to the packaging system or the upload? if the later, what's the outcome? |
I believe it's a packaging issue. I'd have expected fleet-server to generate a child file including all variables:
Furthermore, I realised that the ARM support is different: meanwhile Beats produces files including |
What do we do?
Infra Release team pushed to use the same aarch extension from 8.0 onwards, but they asked to revert this change: We might need to support this :/ |
Definitely, this upload is agnostic to the package command but copy files. See Lines 136 to 154 in c2f9e50
I don't know if that's something to be changed, but the release might be also affected if so. Maybe it's worth to contact the fleet-server team about this package misleading compared to the elastic-agent/beats? |
Acceptance Test
|
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.
With latest changes in elastic/e2e-testing#2172, I think it would be easy to create an edge case for Fleet Server
I'll merge this now |
(cherry picked from commit 65681a3)
(cherry picked from commit 65681a3)
(cherry picked from commit 65681a3) # Conflicts: # .ci/Jenkinsfile
What is the problem this PR solves?
Uses elastic/apm-pipeline-library#1549 in order to upload the packages to a Google Storage bucket.
The folder structure is:
<bucket-name>/fleet-server/snapshots/
<bucket-name>/fleet-server/pull-requests/pr-<id>/
<bucket-name>/fleet-server/commit/<sha>/
<sha>
is the git commit related to the build and package happened in the CIpr-<id>
is the pull request IDTest
produced: