The current method to fetch Beats artifacts comes from
|
func FetchBeatsBinary(ctx context.Context, artifactName string, artifact string, version string, timeoutFactor int, xpack bool, downloadPath string, downloadSHAFile bool) (string, error) { |
, where we are downloading from the beats-ci-artifacts bucket.
The current situation does not allow fetching artifacts for other projects (i.e. fleet-server, elastic-agent) because the current bucket only supports Beats project artifacts, but we would like to consume fleet-server and elastic-agent artifacts too, which ideally would reside under beats-ci-artifacts but namespaced by the project name:
+ beats-ci-artifacts
- beats
- commits
- snapshots
- fleet-server
- commits
- snapshots
- elastic-agent
- commits
- snapshots
Implementation
We could clone the pkg/FetchBeatsArtifact method to pkg/FetchProjectArtifact, and this method would receive one extra parameter with the project name (i.e. beats, fleet-server, elastic-agent), which would be passed downstream to the method responsible of calculating the bucket path.
Then, the existing method would internally call the second one passing beats as project, and we would have it resolved.
@adam-stokes @narph thoughts?
The current method to fetch Beats artifacts comes from
e2e-testing/pkg/downloads/versions.go
Line 357 in 05bf7b1
The current situation does not allow fetching artifacts for other projects (i.e. fleet-server, elastic-agent) because the current bucket only supports Beats project artifacts, but we would like to consume fleet-server and elastic-agent artifacts too, which ideally would reside under beats-ci-artifacts but namespaced by the project name:
Implementation
We could clone the
pkg/FetchBeatsArtifactmethod topkg/FetchProjectArtifact, and this method would receive one extra parameter with the project name (i.e.beats,fleet-server,elastic-agent), which would be passed downstream to the method responsible of calculating the bucket path.Then, the existing method would internally call the second one passing
beatsas project, and we would have it resolved.@adam-stokes @narph thoughts?