[feat req] Add file name and artifact id options

[DrummerB]

What would you like to be added?

Having only a single way to reference and name an artifact can be limiting in certain situations. The current name field is used for 3 different purposes:

• The display name of the artifact, which is shown to the user in the artifact list of a workflow.
• The file name (with extension .zip) of the download.
• The artifact id, which can be used to reference an uploaded artifact for later download in a subsequent job.

I think it would make sense to separate these purposes and allowing to specify and override each of them individually.

Why is this needed?

One problem that would be fixed with this is a setup where you may want to include meta info in the artifact name, which may not be available in later jobs, where you want to download the artifacts again. There are workarounds, but it would be much more elegant to allow specifying

• a dynamic file name, such as Product-${{env.version}}+${{github.run_id}}, which allows identifying where an artifact came from originally,
• a simpler display name, such as Product-${{env.version}},
• and a constant artifact id for easier download in a test job, such as build-results.

[DiegoOliveiras]

It would be great if this was possible:

# in a previous step
echo "{OUTFILE}={my_file.dmg}" >> $GITHUB_ENV
echo "{OUTFILE_PATH}={my_file_path}" >> $GITHUB_ENV

# then on upload artifact step
    - name: Upload artifact
      uses: actions/upload-artifact@v3
      with:
        name: ${{ env.OUTFILE }}
        path: ${{ env.OUTFILE_PATH }}

[stan-spotts]

This is old, but another use case - when you want to use:

az webapp deploy --name ${{ env.APP_NAME }} --resource-group ${{env.RESOURCE_GROUP }} --type zip --src-url ${{ needs.build.outputs.artifact_url }} --async false

and it doesn't understand that the url that doesn't end with .zip is a zip file. The REST API (onedeploy) has the underlying issue. It doesn't look at the http header to see what the file name is, so you get a 400 error. So the option is to add a lot of overhead adding and deleting blob storage just to work around it.

This, of course, is because the real solution (azure/webapps-deploy) doesn't work with private ip, and seems to go against the public dns name of the app service instead of using the management (ARM) API. :(