Path generation issue during workflow run

[Mike Durthaler]

Hello,

 I tried the email g...@vger.kernel.org but this was pinged back.

This issue was encountered during a class demo.  I’m doing a Git course on PluralSight, so there isn’t a production / mission related issue here.  Just a real curious one. 

Here is the code for the build step with step and runner debugging turned on.  See the highlighted error below, it was sitting right in front of me, I just didn’t see it.  Step and runner debugging were not needed: 

##[debug]Evaluating condition for step: 'Run docker build . -t ${{ env.IMAGE_NAME }}'

##[debug]Evaluating: format('docker build . -t {0}', env.IMAGE_NAME)

##[debug]Evaluating format:

##[debug]..Evaluating String:

##[debug]..=> 'docker build . -t {0}'

##[debug]..Evaluating Index:

##[debug]....Evaluating env:

##[debug]....=> Object

##[debug]....Evaluating String:

##[debug]....=> 'IMAGE_NAME'

##[debug]..=> '***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b'

##[debug]=> 'docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b'

##[debug]Result: 'docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b'

##[debug]Set step '__run' display name to: 'Run docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b'

##[debug]Evaluating: success()

##[debug]Evaluating success:

##[debug]=> true

##[debug]Result: true

##[debug]Starting: Run docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b

##[debug]Loading inputs

##[debug]Evaluating: format('docker build . -t {0}', env.IMAGE_NAME)

##[debug]Evaluating format:

##[debug]..Evaluating String:

##[debug]..=> 'docker build . -t {0}'

##[debug]..Evaluating Index:

##[debug]....Evaluating env:

##[debug]....=> Object

##[debug]....Evaluating String:

##[debug]....=> 'IMAGE_NAME'

##[debug]..=> '***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b'

##[debug]=> 'docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b'

##[debug]Result: 'docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b'

##[debug]Loading env

Run docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b

##[debug]/usr/bin/bash -e /home/runner/work/_temp/a0b2d464-3974-4429-8869-5b6b55ad49a1.sh

unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/runner/work/DockerDeployDemoVS22EntRepo/DockerDeployDemoVS22EntRepo/Dockerfile: no such file or directory

Error: Process completed with exit code 1.

##[debug]Finishing: Run docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b

 

DockerDeployDemoVS22EntRepo should be DockerDeployDemoVS22Ent but somehow the DockerDeployDemoVS22EntRepo part of the path segment is duplicated. 

 

Here is a screen shot.  Following is a screen shot of the solution that was pushed up from VS 22 Enterprise.

 e path is being incorrectly constructed, somehow.  Is there a flag that can be set, or something like this, to force the correct path to be created?

 

ere is what was pushed up from VS.  The project name becomes a part of the path, and this is correctly rendered in Git.

 

Does the workflow code in Git expect the project and repo to both be named the same?  I put in ‘Repo’ on all repository names so that I know what’s what when looking at a path.  For me it makes sense.  Did I find a way to break things for Docker related repos?

 

 

 

Michael W. Durthaler

Software Development Specialist

Division of Information Technology

1980 W. Broad Street, Columbus, Ohio 43223

614.466.1065

transportation.ohio.gov

 

[Konstantin Khomoutov]

On Fri, Jun 30, 2023 at 07:14:56AM -0700, Mike Durthaler wrote:

> I tried the email g...@vger.kernel.org but this was pinged back.

Their filter outright rejects mails which contain HTML parts - even if there
is an alternative plain text part (like in this your message).

If you're using GMail web interface, try clicking "Remove formatting" or
ticking "Plain text mode" in the message's window settings - see [1].

[...]

> Here is the code for the build step with step and runner debugging turned
> on. See the highlighted error below, it was sitting right in front of me,
> I just didn’t see it. Step and runner debugging were not needed:
>
> ##[debug]Evaluating condition for step: 'Run docker build . -t ${{
> env.IMAGE_NAME }}'

[...]

> unable to prepare context: unable to evaluate symlinks in Dockerfile path:
> lstat /home/runner/work/DockerDeployDemoVS22EntRepo/
> DockerDeployDemoVS22EntRepo/Dockerfile: no such file or directory
>
> Error: Process completed with exit code 1.

Do I assume correctly that it's formatting, and the error message was a single
line with a full pathname - that is, there was no line break after
"...EntRepo/"?

[...]

> DockerDeployDemoVS22EntRepo should be DockerDeployDemoVS22Ent but somehow
> the DockerDeployDemoVS22EntRepo part of the path segment is duplicated.
>
> Here is a screen shot. Following is a screen shot of the solution that was
> pushed up from VS 22 Enterprise.
>
> [image: RepoShowingDockerFileAndCorrectPath.png]e path is being
> incorrectly constructed, somehow. Is there a flag that can be set, or
> something like this, to force the correct path to be created?
>

> Here is what was pushed up from VS. The project name becomes a part of the

> path, and this is correctly rendered in Git.
>
> [image: VS_Showing_Proj_And_Git_Repo_Names.png]
>
> Does the workflow code in Git expect the project and repo to both be named
> the same? I put in ‘Repo’ on all repository names so that I know what’s
> what when looking at a path. For me it makes sense. Did I find a way to
> break things for Docker related repos?

There are too many moving parts and the question itself appears to be moot.

Points that concern/confuse me:

* There's no such thing as "the workflow code in Git"; what do you mean?

Maybe I'm just falsely triggered by the word "workflow" which these days
in the context of Git usually means something specific to Github's CI.
Do you simply mean "the core Git code" which is working when any Git
command is called to operate on a Git repository?

* Your usage of the words "project" and "repo" in the same context is a bit
suspicious: Git has no concept of "a project" as it only deals with
repositories. A Git repository is just a set of files and directories;
Git puts no meaning in them (well, except for special files such as
".gitattributes" and its special directory named ".git").

So, a hierarchy of files kept in a Git repository might be a VS project
but Git does not know about this.

* If I understood correctly the build step of your project involves calling
into Docker, and googling for the exact error message "unable to prepare
context: unable to evaluate symlinks in Dockerfile path" strongly suggests
it is emitted by Docker.

* Studying screenshots of UIs of IDEs may be misleading: we have no idea
what exactly the IDE chose to display as the project's root - it may have
little relation to the project's actual filesystem path.

OK, that list was a bit haphazard, I admit, but that's the best I could came
up with given limited time I can spend on the issue.
So, what I would try to do:

1) Consider that Git may be well out of the question as the error message
comes from Docker.

2) Try to run that build step outside of IDE _and_ Git: that is, have a copy
of your repo without the Git's ".git" directory in it, and try to run the
build step directly - say, by hand from a console window.

If the issue persists, your problem is most likely related to Docker or
Docker-on-Windows.
Try googling for the error message as I did - it yields a couple of posts
(including posts on SO and SE) which deal with problems like yours; may be
some of them will be of help.


Sorry for not providing a definitive answer; I still hope my analysis and the
pointers I presented might help you move forward.

Footnotes:

1. https://support.google.com/mail/thread/37488263/

[Mike Durthaler]

The excess detail definitely clouded the issue.

The problem is the path made to the docker file when the workflow was run is incorrect.  The green highlighted path section does not exist and thus the docker file can't be found.

It should not be DockerDeployDemoVS22EntRepo, but should be DockerDeployDemoVS22Ent.

I only included all the other debug code, etc. to clarify my question but clearly clouded it instead.

The VS Screen shots were meant to show what was created in the project solution.  And show that GitHub clearly copies this path structure.

The point here is with the correct path structure, /home/runner/work/DockerDeployDemoVS22EntRepo/DockerDeployDemoVS22EntRepo/Dockerfile is incorrect.

When the workflow was run, the path to the docker file should have been /home/runner/work/DockerDeployDemoVS22EntRepo/DockerDeployDemoVS22Ent/Dockerfile.  It is incorrect that 'Repo' exists in the path segment prior to /Dockerfile.

##[debug]/usr/bin/bash -e /home/runner/work/_temp/a0b2d464-3974-4429-8869-5b6b55ad49a1.sh

unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/runner/work/DockerDeployDemoVS22EntRepo/DockerDeployDemoVS22EntRepo/Dockerfile: no such file or directory

Error: Process completed with exit code 1.

##[debug]Finishing: Run docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b

 

DockerDeployDemoVS22EntRepo should be DockerDeployDemoVS22Ent but somehow the DockerDeployDemoVS22EntRepo part of the path segment is duplicated. 

[Mike Durthaler]

Are you getting my replies?

I've copied this again, from below.  It looks like I might have somehow replied to myself:

The excess detail definitely clouded the issue.

The problem is the path made to the docker file when the workflow was run is incorrect.  The green highlighted path section does not exist and thus the docker file can't be found.

It should not be DockerDeployDemoVS22EntRepo, but should be DockerDeployDemoVS22Ent.

I only included all the other debug code, etc. to clarify my question but clearly clouded it instead.

The VS Screen shots were meant to show what was created in the project solution.  And show that GitHub clearly copies this path structure.

The point here is with the correct path structure, /home/runner/work/DockerDeployDemoVS22EntRepo/DockerDeployDemoVS22EntRepo/Dockerfile is incorrect.

When the workflow was run, the path to the docker file should have been /home/runner/work/DockerDeployDemoVS22EntRepo/DockerDeployDemoVS22Ent/Dockerfile.  It is incorrect that 'Repo' exists in the path segment prior to /Dockerfile.

##[debug]/usr/bin/bash -e /home/runner/work/_temp/a0b2d464-3974-4429-8869-5b6b55ad49a1.sh

unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/runner/work/DockerDeployDemoVS22EntRepo/DockerDeployDemoVS22EntRepo/Dockerfile: no such file or directory

Error: Process completed with exit code 1.

##[debug]Finishing: Run docker build . -t ***.azurecr.io/webapp:1d69b259c8cda2e3f63c8511326346689601557b

 

DockerDeployDemoVS22EntRepo should be DockerDeployDemoVS22Ent but somehow the DockerDeployDemoVS22EntRepo part

[Konstantin Khomoutov]

On Wed, Jul 12, 2023 at 05:28:28AM -0700, Mike Durthaler wrote:

> Are you getting my replies?

I do (well, the whole list does, that is) ;-)

> I've copied this again, from below.
> It looks like I might have somehow replied to myself:

I chose to not respond because I had nothing to add to my first reply based on
your comments. I'm an old-timer, so my rule of thumb with regard to posting
to various "broadcasting" venues such as mailing lists is that you do not post
if you have nothing substantial to say - in the hope someone other more
knowledgeable, or with a good insight, will chime in.

Basically, I still stand by everything I wrote in my first reply and has
nothing to add to it. Your post may have cleared up certain bits but none of
these affected my reasoning and conclusions in any way. To recap, my idea is
1) to try to rule out both IDE and Git out of the equation and see if Docker
continues to fail your build; 2) study what others have had discussed
regarding the error message produced by Docker, you're observing.

I'm sorry about the confusion resulting from me having been silent.

[...]