Add a format option for custom inputs

[emmyoop]

trafficstars

Is your feature request related to a problem? Please describe. I have a lot of complex logic involved with formatting my changelog based on kind and custom key that could be eliminated if I could format when generating the yaml.

Describe the solution you'd like I'm not sure how you would refer to it but something like the following so that I could then refer to .Custom.Issue in multiple other places without having to build the link everywhere. I have an added step of complexity where I can refer to two different repos so the value of repo-name is dynamic. It's determined by the Kind so I would actually need to be able to define the custom format per kind.

custom:
  - key: Issue
    label: GitHub Issue Number
    type: string
    customFormat: ([repo-name/#{{.this.input}}](https://github.com/dbt-labs/dbt-docs/issues/{{.this.input}})

Describe alternatives you've considered Continuing to use the more complex templating I'm using. It works 😃

Additional context Add any other context or screenshots about the feature request here.

[miniscruff]

Hmm this is an interesting idea and not something I would of considered. I have one question though. Would you ever need a custom format that includes more than one custom value or a combination of custom values and default body, kind or component values? For example, say a support email was based off component types or something.

I was thinking something like:

custom:
  - key: Issue
    label: GitHub Issue Number
    type: string
    vars:
    - key: Repo
      value: ([repo-name/#{{.value}}](https://github.com/dbt-labs/dbt-docs/issues/{{.value}})

( actual keys subject to change ) But these would be extra values so your output would look something like:

custom:
  Issue: 515
  Repo: ([repo-name/#515])(...)

It would not replace the custom value, but add additional ones just in case you either need more than one, or you still need the original in some other use case.

One more point, if we want to support creating extra vars just before writing to file, we could have a post process sort of config for building extra vars.

post:
  - key: Repo
    value: same as above but can now access all of the changes values using {{.change.XYZ}}

Output file would be the same.

[emmyoop]

I'm not seeing it in the docs (I originally set up changie last spring and you've make some big improvements since then) but it doesn't look like you can have custom inputs per kind, can you?

The post process is interesting. That might fit my needs as I could template out the conditional values based on the .changes.Kind value. And since multiple values are available it would allow for more flexibility. Additionally it prevents anyone that directly edits the yaml from getting the file out of sync!

[miniscruff]

Kinds can have additional choices that mimic custom choices but only when that kind is selected see doc here: https://changie.dev/config/#kindconfig-additionalchoices. You can also toggle the body choice and global custom choices on a per kind level as well.

[miniscruff]

One final point on the kind config is the change format can also be customized per kind, so bugs can use a different format then features and so on ( docs here https://changie.dev/config/#kindconfig-changeformat ). Not sure it would help much but it is an option for you.

[emmyoop]

@miniscruff I am now using that feature as I have different requirements for issues/PRs listed by kind. I'm loving how flexible the config has become.

However, it does not help with formatting the PR number into a full link. Being able to do custom post processing per kind would be the best and safest option here. It would allow building of the link dynamically per kind while minimizing the chance of the yaml file being modified manually and getting out of sync.

[miniscruff]

Ok that feature sounds reasonable, I think it would be best to close this one and open a new post process config for the new command. It should also have a per kind post process as well as a kind config to skip the global post process just like the skip global choices. I think it is also reasonable, for now anyway maybe it will change, to place these values inside the custom section of the generated yaml.

[emmyoop]

Closed in favor of #355