Skip to content
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

[discussion] [docker] Multiple uploaded artifacts & matrix strategy for docker-based #1731

Open
asraa opened this issue Mar 2, 2023 · 1 comment
Assignees
Labels
area:docker-based Docker based builder (supplying a builder image and command) type:discussion A point of discussion

Comments

@asraa
Copy link
Collaborator

asraa commented Mar 2, 2023

This issue is to discuss the output artifacts for the docker-based workflow.

The docker-based workflow allows wildcard artifact paths, say dist/** which may match a number of artifacts and subfolders, for e.g. dist/subfolder/b.txt and dist/a.txt.

When the workflow is complete, they are currently stored in GH artifacts in their subfolders, using https://github.com/actions/upload-artifact#upload-using-multiple-paths-and-exclusions

This preserves the path heirarchy after the first wildcard pattern.

On a GH tag or release event, https://github.com/softprops/action-gh-release supports glob patterns, so we can upload all the artifacts. They will be uploaded as individual files.

Question 1 There is a bit of a mismatch between uploading the path-preserved files in the GH artifacts, and uploading the individual files. Should we remove the path heirarchy preservation and assume that generated artifacts do not need that structure?

Question 2 When using matrix strategy or multiple runs, I believe the build output and provenance folders should be separated in the GH artifact uploads in the workflow. They will be things like build-outputs-RNG_A and build-outputs-RNG_B for each of the matrix strategies. This way you can distinguish between each job in the matrices outputs. Again, for a release, they will all be uploaded as a flat structure to the release. Does that make sense?

cc @rbehjati

@asraa asraa added type:feature New feature or request status:triage Issue that has not been triaged area:docker-based Docker based builder (supplying a builder image and command) and removed status:triage Issue that has not been triaged labels Mar 2, 2023
@ianlewis ianlewis added type:discussion A point of discussion and removed type:feature New feature or request labels Mar 2, 2023
@asraa asraa self-assigned this Mar 9, 2023
@rbehjati
Copy link
Contributor

rbehjati commented Apr 4, 2023

Sorry for the late reply.

Question 1 There is a bit of a mismatch between uploading the path-preserved files in the GH artifacts, and uploading the individual files. Should we remove the path heirarchy preservation and assume that generated artifacts do not need that structure?

I think we cannot generally assume this. Removing the structure will work with the current setup of Oak, but I think that can in general be an annoying restriction for the user.

Question 2 When using matrix strategy or multiple runs, I believe the build output and provenance folders should be separated in the GH artifact uploads in the workflow. They will be things like build-outputs-RNG_A and build-outputs-RNG_B for each of the matrix strategies. This way you can distinguish between each job in the matrices outputs.

This part makes sense to me, and seems to work fine.

Again, for a release, they will all be uploaded as a flat structure to the release. Does that make sense?

Does a flat structure mean that files with the same base name will be overridden?
If that is the case, I think the best thing we can do it to be clear about this behaviour, so that the users configure their artifact_paths accordingly. I think the artifact_path field in the config file gives enough flexibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:docker-based Docker based builder (supplying a builder image and command) type:discussion A point of discussion
Projects
None yet
Development

No branches or pull requests

3 participants