feat: add generate-charmhub-token to optional recipes

[NucciTheBoss]

Pre-submission checklist

• I read and followed the CONTRIBUTING guidelines.
• I have ensured that lint, typecheck, and unit tests complete successfully.

Summary of changes

This PR adds the generate-charmhub-token recipe to optional justfile recipes. I wanted to add this action since it's helpful for generating new Charmhub API tokens for each of our operators. I didn't add an argument for the time-to-live flag because I think:

1. We should just pick a sensible default like 90 days or 1 year.
2. charmcraft only supports seconds as the unit for ttl, and I don't like having to do math when I trying to create a long-lived token for CI pipelines.

Related Issues, PRs, and Discussions

Related to our ongoing work to standardize our justfile format across repositories. I also want us to create a SKILL.md file for the justfile format, and we need more data to accurately inform the LLMs of our various project structures and the appropriate "shape" of our recipes.

Other changes

1. I added justfile syntax highlighting to each of the code blocks in the specification.

Docs

• I have created a pull request to add or update relevant documentation in charmed-hpc/docs or another documentation location.

Or:

• I confirm that this pull request requires no changes or additions to documentation.

Specifications are basically documentation 😅

[dsloanm]

Would this recipe be used frequently? If it's run only once a year by a repo owner, my preference would be to document the charmcraft login command in the release spec instead, to keep the justfile lean and avoid a recipe that external contributors can't/shouldn't run.

[NucciTheBoss]

There's established precedence given that slurm-charms, filesystem-charms, and sssd-operator all have some publicly accessible variant of this recipe. It's quite convenient for generating many auth tokens at once especially in monorepos with repository.py.

As for frequency, we'll use it any time the token needs to be refreshed, or when we need to provide a token to an autonomous system (so not THAT often, but not only once a year). I'd prefer that we opt for our own convenience here as having this recipe makes it for us to generate new tokens without having to worry about the underlying implementation (e.g. single charm vs monorepo with repository.py). It feels a bit clunky to me to have to open a spec document on GitHub and then manually tailor each command to each repository when we could standardize on a single just recipe that we already kind of have present in multiple repositories.

Another idea here is that we could add the concept of a scripts directory to our charms where common devhelper scripts live. This pattern is commonly used by Go projects to help keep the primary Makefile or justfile smaller: https://github.com/golang-standards/project-layout#scripts. Let me know what you think of this idea.

[dsloanm]

We didn't get the chance to discuss this at the sprint but my thought is, from a maintenance perspective, it would be more convenient for us to document the token generation command rather than implement a recipe/script.

My understanding is the charmcraft login command and flags to generate the token are the same across all repos. The name of the charm(s) may be provided to scope the token but not always, e.g. no charm is specified in sssd-operator. In which case, standardizing the generate-charmhub-token recipe would require:

• Per-repo duplication and maintenance of the command. If we want to change the command or if there's a breaking change to charmcraft, the same update would need applying across repos
• This becomes magnified as new charm repos are added

The same would apply to a helper in a scripts directory. Documenting the command:

• Gives a single source of truth
• Only the location in the docs needs updated for command changes
• Adding new charm repos does not require duplicating the recipe
• Generating a new token does not require cloning any repo

Also, given the recipe would be seldom run and requires manual intervention to sign in via a web browser, the scope for automation is limited.

If all our charms were in one monorepo, I think a recipe would be more valuable, as there would be a single implementation and it could programmatically determine the list of charms for scoping the token. However, our setup is individual repos.

What do you think?

[NucciTheBoss]

I disagree that a shared sticky note/code snippet written down in some bespoke location is more convenient than the simple recipe I'm proposing here. Here's why:

1. Most of our charm repositories - sssd-operator, filesystem-charms, and slurm-charms - already have some form of the generate-charmhub-token recipe. I'm just attempting standardize the existing use of this recipe so that it's consistent across our charm repositories. The recipe has already been implemented, maintained, and used across several repositories, so we've clearly found a need for it already.

2. The concern about maintenance feels rather inflated here imho. We already copy several files between repos, so I don't see how adding a 9 line command to make repo maintenance more convenient for ourselves will become an insurmountable thing for us to maintain. It's a copy + paste and move on with our lives. Regarding new repos, that's not an impossible or arduous problem either. It can be solved with either a template repository (which we should have anyways given our reliance on repository.py), or AI automation. I have already been using AI to keep our Terraform modules up to date, and it's not that difficult to do for standard justfiles either.

3. Regarding random changes in charmcraft, as I've stated in previous conversations, I don't consider potential, future breaking changes that haven't even been thought of yet a reason to not do something now. I find it highly likely that if charmcraft we're to introduce a breaking change to charmcraft login, we'd be more likely to fix and patch the script rather than update bespoke developer documentation. I've seen it time and time again where developer documentation becomes out-of-date, is left to rot, and no one updates it because "they just don't have the time"; I don't think we're an exception here either.

4. The justfile isn't for automation, it's for our own human convenience. Our CI pipeline doesn't need the justfile. Us humans need it because we'll never remember all the flags and arguments to pass to pytest just like how we won't remember every permission scope we need to grant a Charmhub token.

5. The point of this recipe is to make the Charmed HPC release managers' lives easier. I personally know that I'd get rather irritated if I had to spend 30 minutes fumbling a GitHub repository full of Markdown documents, find the exact section that I'm looking for, adapt it to my specific problem, only then to forget said command when I need to generate a new token. I'd much rather just call just generate-charmhub-token and be done with it like I already do with just repo generate-token.

My preferred path forward here would be to accept my proposed update to the spec as is because:

• I think there's several cons to the documentation snippet approach that haven't been fully evaluated yet.
• generate-token already exists and is being used within several repositories - it's how we've/I've updated tokens in the past - so I think we should standardize existing usage rather than take away what's already being used.
• If long-term maintenance is a concern, this is a great place to evaluate how AI can be used to automate away tedium.

[dsloanm]

A goal of this standard is to reduce copy + paste duplication across repos and alleviate our DRY maintenance issues. This is an opportunity to improve the current approach.

My suggestion is a single place in the release spec with this command. Release managers look up and run it on the occasion it is necessary. When changes are needed, only one doc needs updated.

My understanding is your suggestion is duplicating the command in justfiles/scripts over all charm repos. Release managers git clone each repo and run the recipes/scripts. When changes are needed, each charm repo requires updating.

I still see the docs approach as both more maintainable and convenient. Given we disagree, I suggest we discuss with the new team manager, if he's happy to comment.