Add CLI vars

[emmyoop]

Is your feature request related to a problem? Please describe.
We first added changie to our core repo. We list all contributors in the footer of every changelog. Our definition of a contributor is someone not on our team. To ensure we don't list our internal team as contributors we have a hardcoded list of GitHub handles in the .changie.yaml to filter our core team members. Every time a team member would leave or join, we have to go in to modify this list to ensure it stays up to date.

After using changie for a few months we decided to expand to use on multiple other repos within our org. Now, when team members change, we have to go update multiple repos with just a handle add or removal. We no longer have a single source of truth and it is easy for this list to get out of sync.

Describe the solution you'd like
We have automated our changelog generation with GitHub Actions. Where I would ideally like to go with this is to be able to query the GitHub Group membership for my team in previous workflow step and grab the members that way. Then pass that list in as a CLI argument (--vars ?) that I can then access in .changes.yaml.

Not sure of the exact syntax but something to this effect:

changie batch --vars '{"core-team": "user1 user2 user3"}

This would allow for a single source of truth as to who our team members are.

Describe alternatives you've considered
Continuing to maintain the list in multiple places.

Additional context
I think it's important to note the .changes.yaml files have differences between the repos as we require different kinds.

[miniscruff]

I was thinking about something sort of similar for a little while so here is my idea.

Two new configuration options related to using environment variables.

env:
    system: true/false # if true, load all environment variables
    prefix: CHANGIE_ # if set, load variables that have this prefix, removing the prefix before storing it

Then, all template structs would include a new variable Env such that you can do {{ env.CORE_TEAM }} however you see fit.

More of a full example:

env:
    prefix: CHANGIE_
versionFormat: "{{.Version}} for {{.Env.PROJECT_NAME}}"

export CHANGIE_PROJECT_NAME=Changie
changie batch patch

I think it also makes sense to add a section of env to store vars directly in the config like:

env:
    define:
        REPO_NAME: dbt-core

Then you can use {{Env.REPO_NAME}} in the changie config in place of copy pasting dbt-core around. And if you reuse a similar file across projects you just need to change one value instead of many.

We could add a --vars KEY=Value similar to how --custom is defined if that works as well, but it would work on top of the envs above.

Not entirely sure on specific keys for env just yet but this sort of idea should solve your issue. But let me know if not.

[miniscruff]

Ok after a little more thought, loading all system env vars is probably not a good idea for now, maybe if someone asks for it.
And instead of env.define I think just using env for custom defined env vars would be fine and a value for envPrefix would work.

envPrefix: CHANGIE_ # empty by default and if not defined, no env vars will be loaded
env:
    PROJECT_NAME: dbt-core # changie config wide values you can use in place of copy paste

# --env would add to the env map[string]string so they would be interchangable
# cli would override existing keys in config
changie new/batch/merge? --env KEY=VALUE

Edit: This sort of follows the env from GitHub actions

[emmyoop]

Environment variables are perfect. It would fit my needs since I can just set an env var within a GitHub action. I cannot come up with a specific reason/use case for the CLI --vars command for changie, honestly. changie isn't a command you're constantly running for every commit/change to your code base so setting an env var doesn't seem unreasonable.

I like the ability to set your own prefix. I think people will find that useful.

[rocktavious]

What if only the envPrefix vars are the ones loaded up automatically - instead of the entire env context. That way its more turn-key instead of having to add a bunch of --env flags to the command which could be cumbersome.

I really like this

env:
    prefix: CHANGIE_
versionFormat: "{{.Version}} for {{.Env.PROJECT_NAME}}"

I would use this in OpsLevel's projects too as we are trying to move to standardize these changie things across all our repos at the org.

[miniscruff]

What if only the envPrefix vars are the ones loaded up automatically - instead of the entire env context. That way its more turn-key instead of having to add a bunch of --env flags to the command which could be cumbersome.

Yea that was the plan with envPrefix

I really like this

The env block was to allow you to specify env vars internally similar to dockerfiles or github actions. They would be hard coded in the config but sharable across template outputs, IE if you wanted to use one value in the version template and kind template. Or say changie format and the footer.

[llaville]

@miniscruff Tell me if I'm wrong, but I don't find anywhere the related section about environment variables in documentation.

[miniscruff]

@miniscruff Tell me if I'm wrong, but I don't find anywhere the related section about environment variables in documentation.

https://changie.dev/config/#config-envprefix if env prefix is specified, all values with that prefix are added to the Env value of most templates.