GitHub Community
Builtin support for artifact sharing #26070
-
|
The current strategy to share artifacts between jobs is to use upload-artifact and download-artifact, which works reasonably enough but can get quite verbose. It would be nice to have a jobs.<job_id>.artifacts section, since it seems to be an often requested feature that fundamentally changes how workflows are written and used. This could also enable artifact sharing between workflows (e.g. an option to specify the target path, which would by default depend on the commit sha and would be local to a push, but could then also be branch/tag specific or even global for the project), for things like shared caches between workflow runs. Any plans to include something like this? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 3 replies
-
|
We do plan to introduce someway to share artifacts between workflows as well as an option for caching between runs of the same workflow. We don’t plan to introduce a specific keyword for artifacts just like we don’t have a keyword for checking out the repository. Actions that you use in your workflow come from GitHub repos and we want all actions whether we create them or another GitHub user creates them to be referenced the same way. The only place where we have decided to deivate from this design is with the run keyword and this is because running a shell script is so common that we felt it needed to simply be built in. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I really appreciate getting the reasoning on decisions like that. I also considered the similarity to actions/checkout when I wrote this post, the reason why I hit “send” anyway is that an artifact action has a lot more possible parametrization, like expiration time and access rights. But in the end it all comes down to how well it’s documented, if that part is good then all is good. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like it is only possible to share artifacts between jobs of the same workflow. How about sharing artifacts between workflows? https://stackoverflow.com/questions/60355925/share-artifacts-between-workflows-github-actions |
Beta Was this translation helpful? Give feedback.
-
|
Its been 6months, any update on sharing artefacts between workflows? |
Beta Was this translation helpful? Give feedback.
-
|
It's been 3 years... cmon guys! |
Beta Was this translation helpful? Give feedback.
-
|
It's super easy in Azure DevOps but it looks like we will have to wait couple more years to have it in Actions. To be honest it's a very important feature when it comes to multienvironment deployments. |
Beta Was this translation helpful? Give feedback.
-
|
Artifact sharing is a core tenet of any CI/CD system. It's 2024 and this still isn't available in GitHub Actions! Embarrassing. |
Beta Was this translation helpful? Give feedback.
-
|
Sharing artifacts between workflows, should be possible as of mid December 2023 if you use both v4 of upload-artifact and download-artifact https://github.com/actions/download-artifact?tab=readme-ov-file#usage # The repository owner and the repository name joined together by "/".
# If github-token is specified, this is the repository that artifacts will be downloaded from.
# Optional. Default is ${{ github.repository }}
repository:
# The id of the workflow run where the desired download artifact was uploaded from.
# If github-token is specified, this is the run that artifacts will be downloaded from.
# Optional. Default is ${{ github.run_id }}
run-id:GHES users need to wait A keyworld for the workflow is not existent. |
Beta Was this translation helpful? Give feedback.
-
|
I must be in luck as I solved my issue using This is how I solved my issue FWIW: |
Beta Was this translation helpful? Give feedback.
We do plan to introduce someway to share artifacts between workflows as well as an option for caching between runs of the same workflow.
We don’t plan to introduce a specific keyword for artifacts just like we don’t have a keyword for checking out the repository. Actions that you use in your workflow come from GitHub repos and we want all actions whether we create them or another GitHub user creates them to be referenced the same way.
The only place where we have decided to deivate from this design is with the run keyword and this is because running a shell script is so common that we felt it needed to simply be built in.