You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Symlinks to tracked directories and files but present in untracked directories are kept, while the directory is clearly expected to be removed from the artifact
Broken Symlinks are kept in tracked folders but also in untracked folders.
By untracked folder I mean a folder excluded in the .gitignore file which is used in acli push:artifact to exclude some of the folders.
/tmp/acli-push-artifact/allowed is almost OK, symlinks to crap dir or files were removed but the broken link is still there. Is this the expected result? Maybe not.
The fact that the broken link was keeped is subject of debate, maybe this link will activate on the targeted env for the artifact.
IMHO we should have a --allow-symlinks options in the artifact generation command, and then all symlinks in the forbidden directory should not be kept and crap/ should not be in the artifact, and all the symlinks in allowed/ should be present in the artifact (even the ones to crap/ and broken links) if we --allow-symlinks and none if we do not.
The text was updated successfully, but these errors were encountered:
regilero
changed the title
Some symlinks broken symlinks are wrongly present in artifact
Some symlinks and broken symlinks are wrongly present in artifact
Sep 18, 2024
github-actionsbot
changed the title
Some symlinks and broken symlinks are wrongly present in artifact
CLI-1403: Some symlinks broken symlinks are wrongly present in artifact
Sep 18, 2024
Description
By untracked folder I mean a folder excluded in the
.gitignore
file which is used in acli push:artifact to exclude some of the folders.To Reproduce
After artifact generation:
Expected behavior
/tmp/acli-push-artifact/crap/
should not exists/tmp/acli-push-artifact/allowed
is almost OK, symlinks to crap dir or files were removed but the broken link is still there. Is this the expected result? Maybe not.The fact that the broken link was keeped is subject of debate, maybe this link will activate on the targeted env for the artifact.
IMHO we should have a --allow-symlinks options in the artifact generation command, and then all symlinks in the forbidden directory should not be kept and
crap/
should not be in the artifact, and all the symlinks inallowed/
should be present in the artifact (even the ones tocrap/
and broken links) if we--allow-symlinks
and none if we do not.The text was updated successfully, but these errors were encountered: