-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(pipelines): additionalinputs cannot mount deep directory #16936
Comments
This feature was never intended to add files to an existing directory, just to conveniently "mount" the input somewhere in the directory space. If you want to merge directories together, the way to do that would be to add a We're going to have to make it throw an error when you try to do that. Thanks for reporting. |
Hi @rix0rrr , thanks for looking at this. I think you have misunderstood what is happening: I am not trying to put the inputs into a directory that already exists, rather the current logic causes the destination directory to exist if it is more than one level away from The fix is quite trivial, as shown in the main description. |
Oh I see what you're saying. You're right, I misread. |
If the directory is nested deeper than one level underneath `.` or `..`, the wrong directory gets created. Also add in protection against the directory already existing, in which case the same behavior would happen. Fixes #16936.
If the directory is nested deeper than one level underneath `.` or `..`, the wrong directory gets created. Also add in protection against the directory already existing, in which case the same behavior would happen. Fixes #16936. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
If the directory is nested deeper than one level underneath `.` or `..`, the wrong directory gets created. Also add in protection against the directory already existing, in which case the same behavior would happen. Fixes aws#16936. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
What is the problem?
As part of a CodePipeline, if I specify an additional input that should be placed somewhere within the primary input tree, that input appears within another directory inside the directory that it should be in.
As an example, with this configuration:
I would expect the files from
frontend_build
to appear insideweb/dist/
in the tree. However, in fact they appear underweb/dist/01/
.I have determined the cause, and it is here (this isn't the commit that added the bug, just a recent permalink):
That is: if the additional input should be placed anywhere other than one directory away from the build root (in my example it is two away), then that directory is created first. But now the subsequent behaviour of
ln -s ...
changes:ln -s -- source dest
will place
source
atdest
if it doesn't exist, but indest
if it does.The solution is straightforward: just drop one directory from the
mkdir
call:Reproduction Steps
A simple minimal reproducible bit of code is difficult to produce with pipelines due to the nature of the sources. Assuming you have a bootstrapped environment and a standard
cdk.json
file, put this intoapp.py
, add any source entity that you have access to where noted, and deploy. The pipeline will fail in its Synth step because I'm not creating acdk.out
directory, but the log output of that step should show thatfile_from_src2
is inweb/dist/01/
rather thanweb/dist/
where it should be.What did you expect to happen?
I expect the files from the additional inputs to appear directly in the directory that I have configured.
What actually happened?
The files from the additional inputs appear in a directory
01/
inside the directory that I have configured (I assume if more than one additional input is configured, subsequent ones will go to02/
,03/
, etc).CDK CLI Version
1.126.0 (build f004e1a)
Framework Version
1.126
Node.js Version
v16.10.0
OS
Debian Linux
Language
Python
Language Version
3.8.12
Other information
See above for suggested fix.
The text was updated successfully, but these errors were encountered: