Setting Started Features

[ChristianKniep]

Love the project! I'm trying to get a golang-cli template up and running.
Couple of things I feel are missing atm:

• chmod of destination files: When writing scripts via template the destination mode is always 0644. Would be nice to take the sources permissions and apply it to the destination
• do not overwrite: I am bootstrapping an ENV file which should be filled afterwards by the user. I'd like that one to not be overwritten in case it is already present. Something like overwrite: false would be nice.
• default values: Is there a chance to get the {{ . project.name }} as a default variable since it is an argument to the CLI.
• value flags: for the CLI it would also be nice to have something like --value key=value --value key2=val2 so that I do not have to tweak the YAML file but rather have it be added to the CLI command.

[cbrgm]

Hey @ChristianKniep ! Nice to meet you!

• chmod of destination files: I completely agree with the need for this feature. It's crucial for preserving script executability. A practical approach would be to clone file permissions from the source to the destination automatically as you stated already. I just wonder if it would also make sense to make this configurable as an attribute in the config. As files can also be downloaded from an url via http, I assume it would be cool to add this attribute instead of setting a default value in this case.

projects:
  completeDirectory:
    - destination: "config/"
      source: "templates/config_directory/"
++    permissions: 0644
      values:
        appName: "MyApp"

repositories:
  - name: "directory-project"
    groups:
      - groupName: "completeDirectory"

• do not overwrite: I see the importance of this feature, especially for safeguarding user-customized files like ENV configurations. A simple implementation could be adding an overwrite: false flag to protect existing files from being overwritten as you said. When building the v1 version here I wanted to actually add the file sha to the lockfile so one could also make manual changes visible when using the diff command. But I skipped that because the problem here is one would have to render all the files first in memory and then calculate the sha in order to compare it against the file present in the target directory..

• default values: This is a great suggestion. Automatically pulling in the project name into templates would streamline the process I agree. I'm doing some sort of workaround for my private projects at the moment by writing the project name into a value name and use this one in the files instead of having a pre populated one.

• value flags: I'm on board with this idea. It would significantly enhance the CLI's flexibility, allowing users to pass additional parameters directly just like in Helm Charts et al. .

Let's see if I can find some spare time to make some of your ideas happen. Thanks!

[github-actions]

This issue is idle because it has been open for 14 days with no activity.