[411111111111111]

> CI/CD has no business changing your code; it builds stuff using it, exactly as if commit such-and-such.

That going too far unless you define code to be a subset of the files checked into the repository and simply define any file that's touched in an automated manner to be not code

There are a lot of useful automations that can be part of the CI/CD pipeline, such as increasing a version number, generating a changelog, creating new deployment configuration etc

They don't have to be part of it and it's possible to work around it/don't commit... But that comes with it's own challenges and issues

[nine_k]

It's not about not trusting automated generation of certain artifacts. Stamping version numbers may be a fair idea. (A changelog entry needs human review and approval, in my book.)

It's mostly about the flow of data and control: source files, beside some known auto-generated files / single lines, are the source, and whatever is generated is downstream from them, not altering them. It's like a React app: data flows through props in only one direction, you don't patch DOM in event handlers, or something.

[411111111111111]

Its completely fine if you wish to treat your repository like that, but that doesn't make this treatment the only viable and correct way.

There are a lot of people which include their helm package as part of their project repository and even more that generate the changelog from standardized git messages like conventional commits and still wish to persist them in a changelog.md inside of the repository to make completely banal examples spelled out to the letter. It works well and lets you scale these things pretty well inside of a corporation with a lot of teams.

Its completely fine to keep all that out of your automated pipeline, triggering only after these things have occured... but that's not the only viable choice a developer can make and you're very much talking from of an extremely limited perspective if thats your point of view.