Skip to content
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

file.Write doesn't respect outputDir #2057

Open
hojerst opened this issue Apr 29, 2024 · 4 comments
Open

file.Write doesn't respect outputDir #2057

hojerst opened this issue Apr 29, 2024 · 4 comments

Comments

@hojerst
Copy link

hojerst commented Apr 29, 2024

Currently file.Write doesn't respect the outputDir set via config or command line. As it is also not possible to access the set outputDir via a well known var/context var, the only workaround is passing another context var with the outputDir manually and construct output paths manually. However, this falls apart as soon as the outputDir is set outside of the current working directory because of its security check.

IMHO the "working directory" in context of file.Write should be the outputDir set and not the current directory.

@hairyhenderson
Copy link
Owner

Sorry for the delay...

Limiting file.Write to the current working directory (and subdirectories) was a deliberate choice for security purposes, but I do see (after digging way back) that I did originally consider allowing setting the current working directory as a command line option: #485 (comment)

To be honest, this still doesn't seem required to me, as it's quite straightforward to just cd to the right location before running gomplate.

Changing the behaviour to use the outputDir (if it's even set!) would cause significant breakages with existing uses so I'm not keen on that at all.

@hojerst
Copy link
Author

hojerst commented May 25, 2024

well you are right about being able to cd to the target regarding the output dir, however all included templates / configs are also relative to the current working directory.

in my usecase i want to store a config and multiple templates in a git repo and generate templates in another output folder somewhere outside of the git repo. (i.e. all paths in the config should be relative so the git repo can be checked out anywhere and generation just works). if i cd into the output first, the config needs to have abolute paths; if i run everthing from the template directory the generation fails because of the "not in workdir rule".

in my opinion the rule to allow file generation below the output folder only makes more sense as the current one, because when i specify an output folder, i don't really expect something to even be able to generate in my current working directory or somwhere outside of the output directory. maybe thats just me, though.

@hairyhenderson
Copy link
Owner

Thanks for the feedback @hojerst - I think I understand...

Here's a question - when you use file.Write, are you also rendering regular templates into the outputDir? Or are you just expecting outputDir to affect file.Write's working directory?

@hojerst
Copy link
Author

hojerst commented May 26, 2024

currently i'm actually doing both (normal templates and dynamic files with Files.Write). I'm happy with some refactoring though.

I basically use gomplate as a docs generator: I parse a source repo with an analyzer to generate a yaml file with descriptions of code in a structured format. this single yaml file is then passed to gomplate to generate different kinds of output formats. for example an bunch of markdown files for a hugo based website or a single markdown README. (output format is based on the inputDir/config file, while the input yaml is the same regardless of output format).

so to clarify: in a single run currently have formats which generate just a bunch of dynamic files based on dynamic inputs. and some are with a wellknown output file(s) with dynamic contents. sometimes both at the same time (like a index file which is always named the same and some dynamic files based on inputs)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants