🐛 (applyconfiguration): applyconfiguration: add a `year` option to pin the copyright year in generated file headers, matching the object generator and avoiding annual diffs on regeneration. by camilamacedo86 · Pull Request #1379 · kubernetes-sigs/controller-tools

camilamacedo86 · 2026-04-18T04:40:30Z

What

Add a year=<value> option to the applyconfiguration generator, matching the existing object generator.

Why

Today, the applyconfiguration generator passes the boilerplate header directly to the applyconfiguration-gen, which replaces YEAR with the current calendar year at generation time.

For example:

# boilerplate.go.txt
Copyright YEAR The Kubernetes Authors.

Without a year= option:

Jan 2024: make generate → Copyright 2024
Jan 2025: make generate again (even with no API changes) → Copyright 2025

This results in a large, unnecessary diff every January.

The object generator already supports year=, producing deterministic output without annual copyright churn. This change brings the applyconfiguration generator to the same behavior.

Example:

Dec 31 — your generated files say Copyright 2024. The working tree is clean.
Jan 1 — a teammate (or CI) runs make generate. Nothing in the API has changed, but the generator now stamps Copyright 2025 into every generated applyconfiguration file.
Result — every generated applyconfiguration file changes, producing a large, meaningless diff caused solely by the calendar rolling over. That is the problem solved here.

How

Before invoking the upstream generator, this change:

Reads the boilerplate header.
Replaces YEAR with the configured year= value.
Writes the result to a temporary file.
Passes the temporary file to the upstream generator.

Because YEAR has already been replaced, the upstream generator has nothing left
to substitute with the current calendar year, so the configured year remains
unchanged.

For example, with year=2024:

Jan 2024: make generate → Copyright 2024
- Jan 2025: make generate → still Copyright 2024

This pins a single year for the entire generation run, matching the behavior of the object generator. It does not preserve the existing copyright year of individual generated files.

References

Discussion: 🐛 (applyconfiguration): applyconfiguration: add a year option to pin the copyright year in generated file headers, matching the object generator and avoiding annual diffs on regeneration. #1379
Existing year= support for object: ✨ Add header and year options for yaml generator #544
gengo performs the YEAR substitution: https://github.com/kubernetes/gengo/blob/5ee0d033ba5bcb073f0e69c32057520b82d75ccb/v2/execute.go#L59
Kubernetes removed the year to avoid annual churn: Remove YEAR field of all generated files and fix kubernetes boilerplate checker kubernetes/kubernetes#59172
Issue in Kubebuilder Feature Request: Support YEAR placeholder in hack/boilerplate.go.txt kubebuilder#5553

Fixes: #1371

k8s-ci-robot · 2026-04-18T04:40:41Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: camilamacedo86
Once this PR has been reviewed and has the lgtm label, please assign joelanford for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

camilamacedo86 · 2026-04-18T06:06:15Z

@JoelSpeed I think this one is your baby :-)

k8s-triage-robot · 2026-04-18T08:20:53Z

Unknown CLA label state. Rechecking for CLA labels.

Send feedback to sig-contributor-experience at kubernetes/community.

/check-cla
/easycla

alvaroaleman

/hold

For the discussion in #1371

camilamacedo86 · 2026-04-19T05:56:03Z

Hi @alvaroaleman

Thank you for looking on this one.
But it is problematic, I added in the header and in the issue why it is problematic
The problem is in a project we can have both scenarios, with SSA and not then it does not work well.

Consistent behaviour is a key and expected.
So, I do see only 2 options here:

a) Fix and ensure consistency
b) No longer support pass the YEAR in any. (but that would be breaking change and besides k8s no longer care about the YEAR anymore, many end users and projects care so I would not go in this direction)

Vaishnav88sk · 2026-05-25T06:53:48Z

I see this has a do-not-merge/hold on it, is there an open question this is blocked on, or just waiting for review? Happy to take a closer look once the hold is resolved.

camilamacedo86 · 2026-05-26T13:38:34Z

Hi @Vaishnav88sk

I see this has a do-not-merge/hold on it, is there an open question this is blocked on, or just waiting for review? Happy to take a closer look once the hold is resolved.

@alvaroaleman blocked it for discussion: #1379 (review)

As I described in #1379 (comment) IMO it is a bug and must be done or we should not support the YEAR at all.

JoelSpeed · 2026-06-29T12:14:40Z

+			tmpFile.Close()
+			os.Remove(tmpFile.Name())


What if these error?

JoelSpeed · 2026-06-29T12:15:26Z

+		{
+			name:           "YEAR without space not replaced",
+			headerContent:  "CopyrightYEAR YEAR",
+			year:           "2024",
+			expectedOutput: "CopyrightYEAR 2024",
+		},


Does this match what DeepCopy generator would do in the upstream code-generator repo?

Yes, that is the intention.
I changed the tests for use gingo.
But we are covering here the scenarios to ensure that it works like object.

Both should work at the same way.

kubernetes-prow · 2026-07-03T23:18:22Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: camilamacedo86
Once this PR has been reviewed and has the lgtm label, please assign joelanford for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

camilamacedo86 · 2026-07-04T08:52:49Z

Hi @alvaroaleman @JoelSpeed @sbueringer @felix-kaestner @liggitt,

I've updated the PR description to better explain why the YEAR placeholder is needed.

controller-tools is consumed by many projects, and the object generator already supports year=. This PR simply brings applyconfiguration in line with that existing behavior.

Supporting year= avoids the January 1 regeneration issue while remaining fully backwards compatible.

If we decide to remove the YEAR placeholder in the future, I think that should be done consistently across all generators and templates, as a separate breaking change. This PR only fixes the inconsistency in applyconfiguration.

JoelSpeed · 2026-07-07T16:48:14Z

@camilamacedo86 I'm not following how the code enables the files to retain their previous year. As far as I can see the generator has a static year which it dumps into the header file, and then the generator runs and substitutes that one file for all assets it generates

What am I missing?

camilamacedo86 · 2026-07-08T13:46:36Z

Hi @JoelSpeed

Thank you for taking the time to look into this and all your support !!

I've updated both the PR title and desc to make the intent clearer. Hopefully they're easier to follow now. AI also helped me here to wording better.

So "retain the previous year" was the wrong wording. What this PR actually does is pin a single configured year so regeneration no longer rewrites it to the current calendar year. It does not read existing generated files and preserve each file's copyright year. It make the behaviour consistent accross the project (object and apply works at the same way) and solve the Jan 1 issue.

Today, the applyconfiguration generator passes the boilerplate header directly to the applyconfiguration-gen, which replaces YEAR with the current calendar year at generation time.

For example:

# boilerplate.go.txt
Copyright YEAR The Kubernetes Authors.

Without the year= option, here's the Jan 1 problem concretely:

The applyconfiguration-gen replaces YEAR with the current calendar year every time it runs. That means the copyright year in generated files is tied to the wall clock, not to when the code actually changed.

Dec 31 — your generated files say Copyright 2024. The working tree is clean.
Jan 1 — a teammate (or CI) runs make generate. Nothing in the API has changed, but the generator now stamps Copyright 2025 into every generated applyconfiguration file.
Result — every generated applyconfiguration file changes, producing a large, meaningless diff caused solely by the calendar rolling over. That is the problem solved here.

For example, with year=2024:

This pins a single year for the entire generation run, matching the behavior of the object generator. It does not preserve the existing copyright year of individual generated files.

The goal is simply to achieve parity with the object generator and produce deterministic output.

k8s-ci-robot requested review from alvaroaleman and chrischdi April 18, 2026 04:40

k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Apr 18, 2026

camilamacedo86 force-pushed the add-year-backwords branch from c4c3d7f to ca8c426 Compare April 18, 2026 06:05

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Apr 18, 2026

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Apr 18, 2026

alvaroaleman reviewed Apr 18, 2026

View reviewed changes

k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 18, 2026

camilamacedo86 requested a review from alvaroaleman April 19, 2026 05:56

camilamacedo86 changed the title ~~🐛 Add year option to applyconfiguration generator to ensure consistency behaviour~~ 🐛 (applyconfiguration): Add year option to generator to ensure consistency behaviour Apr 20, 2026

camilamacedo86 mentioned this pull request Apr 27, 2026

Inconsistent handling of YEAR substitution across generators #1371

Open

JoelSpeed reviewed Jun 29, 2026

View reviewed changes

camilamacedo86 force-pushed the add-year-backwords branch from ca8c426 to 1eb5542 Compare July 3, 2026 23:18

camilamacedo86 force-pushed the add-year-backwords branch from 1eb5542 to 92c99ad Compare July 3, 2026 23:37

Add year option to applyconfiguration generator

7c6fd5d

camilamacedo86 force-pushed the add-year-backwords branch from 92c99ad to 7c6fd5d Compare July 3, 2026 23:48

camilamacedo86 requested a review from JoelSpeed July 5, 2026 05:01

Uh oh!

Conversation

camilamacedo86 commented Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Why

How

References

Uh oh!

k8s-ci-robot commented Apr 18, 2026

Uh oh!

camilamacedo86 commented Apr 18, 2026

Uh oh!

k8s-triage-robot commented Apr 18, 2026

Uh oh!

alvaroaleman left a comment

Choose a reason for hiding this comment

Uh oh!

camilamacedo86 commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Vaishnav88sk commented May 25, 2026

Uh oh!

camilamacedo86 commented May 26, 2026

Uh oh!

JoelSpeed Jun 29, 2026

Choose a reason for hiding this comment

Uh oh!

JoelSpeed Jun 29, 2026

Choose a reason for hiding this comment

Uh oh!

camilamacedo86 Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kubernetes-prow Bot commented Jul 3, 2026

Uh oh!

camilamacedo86 commented Jul 4, 2026

Uh oh!

JoelSpeed commented Jul 7, 2026

Uh oh!

camilamacedo86 commented Jul 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

camilamacedo86 commented Apr 18, 2026 •

edited

Loading

camilamacedo86 commented Apr 19, 2026 •

edited

Loading

camilamacedo86 Jul 3, 2026 •

edited

Loading