S3 artifact input files have altered timestamps with new version of Argo #12885
Labels
area/artifacts
S3/GCP/OSS/Git/HDFS etc
P3
Low priority
type/bug
type/regression
Regression from previous behavior (a specific type of bug)
Pre-requisites
:latest
What happened/what you expected to happen?
A team in my organization is using Autotools to build their binaries.
Previously they built their binary in one step and used the support in Argo workflows for s3 artifacts to store them.
Then they would use the s3 artifact input in other steps to reuse the already compiled binary.
This worked fine in Argo v3.3.10 but after an upgrade to Argo v3.4.10 and also with Argo v3.5.5, which was the latest helm chart version at the time I was testing, this stopped working right.
The make command has a mechanism to check that the binary files are newer than source code files based on the last modified timestamp, then determines if it needs to recompile the source code or not.
After some investigation I found that this issue: #7486, removed some binaries for internal use in Argo and among those was the tar binary.
The standard library "common/gzip" is now used but this library seems to produce a different modify timestamp compared to how it was previously.
I did some simple artifact output and input test to see if I could see some discrepancies in the timestamps.
I found that the input artifact now has a modified timestamp that seems to match when the file was downloaded and untarred, instead of one that more closely aligns with when it was first created as an output.
The expectation here is that the this modify timestamp would be similar to how it was before to avoid running into problems with the make command.
Logs from Argo v3.3.10
Step: generate-artifact
Container: main
Container: wait
Step: consume-artifact
Container: main
Container: init
Logs from Argo v3.5.5
Step: generate-artifact
Container: main
Container: wait
Step: consume-artifact
Container: main
Container: init
Version
3.5.5
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: