Support resulting an error code when using --fail-no-op=true and spec file

[arrow0108]

Dear Jfrogs,

When I use --fail-no-op=true with file download everything works fine but when using a spec file I think the behavior should change.
If a path specified in a spec file is not fulfilled (no file was downloaded) - the operation should return an error code.

I hope this sounds reasonable.

[liron-shalom]

Thanks for reporting this issue @arrow0108 !
fail-no-op flag is supported when using source & target path arguments and when using a spec-file.
As explained in the documentation, if fail-no-op set to true, the command will return exit code 2 in case of no files are affected.
In case of spec-file with multiple file entries, in case no files were downloaded at all (for all file groups), error code 2 will be returned.
If this is your case, and you wand to get an acknowledgement for a specific group in your spec-file I think running it separately in a dedicated spec-file might be a proper solution.

Can you please share with us your use case and file-spec and let us know what the desired result you wish to get?

[arrow0108]

Hi Liron,

In our case - indeed we have one spec file to download a set of artifacts.
As part of our build process we gather all files (dependencies) from Artifactory and compose a delivery artifact.
So if one of the files mentioned in the spec is missing we will not get a CLI error.

I understand the workaround suggested, separate to several files but I think the CLI got a spec file and didn't fulfill it should return an error.

Thanks

[liron-shalom]

@arrow0108 , thanks for your reply!

I think that for this kind of use case we'll need to add some kind of "fail-no-op" property to the file-spec schema that will act differently from the "global" flag provided to the command.
With that kind of property inside, we will be able to stop executing and fail the operation once a "file" entry with that property set to true will affect no files.
The outer flag behaviour will stay as today, and fail the operation based on the entire command.

Please let us know what do you think of that solution.

[arrow0108]

Sounds ok I guess or a new --fail-part-op (for partial operations :-) )

[avojak]

The current behavior seems counter-intuitive. Given the list of elements in the JSON spec file, I would've expected that the --fail-no-op would apply to each element rather than just the whole, similar to how --limit=1 is applied to each element in the spec file rather than only downloading one element from the whole file.

A fail-no-op property sounds like a viable solution as well.

[ntrainor1]

Agreed. Given the developer's expectations going from jfrog command to the file specs, I would have expected that given a single failure among multiple artifacts in a file spec would trigger an error code 2.

[thecrabrangoon]

I agree that fail-no-op should either:

• apply to each pattern in a spec file
• each pattern in a spec file should have a separate fail-no-op property

I am currently experiencing an issue where if certain patterns fail to download any files, this "error" is silent. The only way to confirm if the download really succeeded is to dig through a long log file.

[pll]

+1 for this. I've got a similar situation where I have a spec-file to download a collection of artifacts. If any of them are NOT downloaded, I want to immediately fail my pipeline.

Currently, I'm not getting a failure code if a single artifact is not downloaded and no way to know which one isn't.

[pstsef-blackberry]

Same situation here, and it seems like a very common scenario. There must be a way to validate that ALL the entries in the spec file are successful

[github-actions]

This issue has been marked as stale due to 6 months of inactivity. As part of our effort to address every issue properly, please feel free to remove the stale label or keep this issue active by leaving a comment. Otherwise, it will be closed in 7 days

[pstsef-blackberry]

Are there any updates to this issue?

[eishaq]

Tested with JFrog Platform Enterprise Plus 7.98.14

We are facing the same issue with our automation processes. Its all but intuitive to fail for cases where any of the item within the spec file fails to get uploaded/downloaded/copied etc.

An update on this topic will be much appreciated.