update automation for 2025

[mildwonkey]

We're somewhat stuck in an awkward position in that the new copyright header tool (that can automatically update all files, and also automatically handles the {firstyear, lastyear} style header) isn't publicly available as a binary. This PR updates our automation so at least new files will get the correct header and it can continue to run in automation.

We will need to update this file in 2026, and run the fork of the copyright tool (built locally) to update these files with the correct year. Ideally by then we can also just use that tool directly (in automation), instead of running two tools, but that's up to the team that owns the tool.

[mohanmanikanta2299]

Hey @mildwonkey ,
From the comments what I can infer is that if a binary is made available for the internal tool which we are using, that can be integrated with your automation put into place ? Correct me if I am wrong.

In that case, give us some time, we'll discuss on this as we intend to make the internal tool available to all users if that eases up the updation process without our intervention.

However, we also are yet to explore whether we need to update all the files of a repo next year or only those files that are modified. Currently, updating headers is just a one time thing which we intend to do.

C.C - @mallikabandaru

[mildwonkey]

@mohanmanikanta2299 - that's an option, but I could have been more accurate there! A binary could certainly work, as long as we have a way of using it in a github action. That's the key detail: accessible by actions.

Today, the action calls go run github.com/hashicorp/copywrite@latest headers, and we'd like to swap that out with the new fork. We can't easily do that with the new tool because the repo is private. There are multiple ways of solving this; the one that would be easiest for all the projects using the tool already might be setting up the repo so the github action can auth with a token (no sso hoops), or can we make the new repo public? A binary that we can easily install/use in an action is also an option.

[SarahFrench]

+1 to what @mildwonkey said. If a public repo is not an option, here is an example of enabling public repos to access tools from a private repo from elsewhere in the company: https://github.com/hashicorp/security-scanner?tab=readme-ov-file#for-public-repositories