Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not A Defect
Description
Hi, we have parameterized job which uses file uploads as argument.
If we take a look at any executed job parameters, before 2.235.1 we see (as example):
If you try to download this file - you get file with name bin_Files.7z, which is expected.
But since 2.235.1 we start seeing:
if you try to download such argument back - you get file with name ARCHIVE_TO_BISECT, without any extension. So it is kind of confusing. You can easily mixup files that you downloaded from the server, and you also need to remember its extension.
Attachments
Activity
Alexander Antonov
added a comment - danielbeck
But at the same time you keep environment variable with real name of the file when we run the job.
That is a little bit weird, I dont understand why you decided to not keep original name of the file, that is not a lot of information to store but it allows you to avoid confusion.
Were there any discussions about this change? I just want to take a look at this discussion, maybe I'll better understand reasoning behind this.
Alexander Antonov
added a comment - danielbeck
But at the same time you keep environment variable with real name of the file when we run the job.
That is a little bit weird, I dont understand why you decided to not keep original name of the file, that is not a lot of information to store but it allows you to avoid confusion.
Were there any discussions about this change? I just want to take a look at this discussion, maybe I'll better understand reasoning behind this. Side effect of a security fix followup to align how we serve files from file parameters with those from workspaces, archived artifacts, etc.
This is deliberate. The parameter name is the file name of the file in the workspace, and that's what's exposed to download.