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
I am running bingo in a CI context, with the current working directory name being unpredictable (e.g. /builds/12345/90345/wd)
Im also pointing GOPATH to a location inside the CI
working directory for the purpose of caching. as a
result GOBIN also points to a path inside the working
directory.
I am setting up the build workspace using bingo get -l and sharing the cached data between
CI jobs.
bingo creates the symlinks with absolute paths,
which makes them unusable in CI jobs other than the
one which ran bingo get -l, as the links point to
nonexistend locations
(e.g. /builds/12345/90345/wd/.cache/golang/bin something when the job working directory is /builds/12345/91112/wd)
As far as i am aware, relative symlinks are supported
on all OS bingo supports.
Is there any objection to creating the symbolic links
relative to the actual binary?
(e.g. instead of /go/bin/something -> /go/bin/something-1.2.3, create /go/bin/something -> something-1.2.3)
The text was updated successfully, but these errors were encountered:
UiP9AV6Y
added a commit
to UiP9AV6Y/bingo
that referenced
this issue
Feb 28, 2025
since the installed binary as well as the symlink reside in the
same directory, relative paths should be safe to use without
having to worry about crossing filesystem boundaries.
closesbwplotka#158
I am running
bingo
in a CI context, with the current working directory name being unpredictable (e.g./builds/12345/90345/wd
)Im also pointing GOPATH to a location inside the CI
working directory for the purpose of caching. as a
result GOBIN also points to a path inside the working
directory.
I am setting up the build workspace using
bingo get -l
and sharing the cached data betweenCI jobs.
bingo
creates the symlinks with absolute paths,which makes them unusable in CI jobs other than the
one which ran
bingo get -l
, as the links point tononexistend locations
(e.g.
/builds/12345/90345/wd/.cache/golang/bin something
when the job working directory is/builds/12345/91112/wd
)As far as i am aware, relative symlinks are supported
on all OS bingo supports.
Is there any objection to creating the symbolic links
relative to the actual binary?
(e.g. instead of
/go/bin/something
->/go/bin/something-1.2.3
, create/go/bin/something
->something-1.2.3
)The text was updated successfully, but these errors were encountered: