Add support for branches other-than main

[kipz]

Right now, the actions and CLI are hard-coded to main, but folks (read me) might use other default branch names, or even not use the default branch as the base branch.

This PR:

• Adds default-branch detection as the default (if that fails, main is chosen)
• Adds base-branch configuration to .tuf-on-ci-sign.ini
• Adds base-branch configuration to signing-event action
• Adds _git_utils.py for some shared git fns and dedupes some _git fns.

My main concern is about the default-branch detection and whether or not it might break some folks who have a main branch that isn't their default branch, though this is probably rare. It might be safer to remove the detection and just default to main.

[jku]

Thanks, I'll have a good look later this week.

[jku]

Right now, the actions and CLI are hard-coded to main, but folks (read me) might use other default branch names, or even not use the default branch as the base branch.

I totally agree with the "I want to run tuf-on-ci on a default branch that is not main" use case. I'm not as sure about the "I want to run tuf-on-ci on a non-default branch" use case though.

What's your take on that? I think I'm ok with the "API changes" here (the added action argument and the new signer config item) if you believe the use case is real... but I can't help but think that we could likely support the first use case without adding that complexity.

[kommendorkapten]

How about just rely on the config/action argument file for the branch name (and default to main if not set)? This would simplify a lot as the branch detection logic would not be needed.

[jku]

How about just rely on the config/action argument file for the branch name (and default to main if not set)? This would simplify a lot as the branch detection logic would not be needed.

I've looked at the PR again and I don't really see how it simplifies a lot -- the only thing I see is removing the git symbolic-ref call... and to me git symbolic-ref seems like the correct solution here: Using "main" is clearly wrong and exposing configuration as a workaround for that doesn't feel right either if we don't at least try to do the right thing first.

I think the question is is there any reason ever to run tuf-on-ci on non-default branch? I don't think there is and that would imply that we could avoid the configuration

[jku]

if we decide to avoid configuration and just use the default branch, we can use
something like base: context.payload.repository.default_branch here

(I think that's the correct path but the documentation is confusing to me so that definitely requires testing)

[kommendorkapten]

is there any reason ever to run tuf-on-ci on non-default branch?

I don't think so? This can be updated in the documentation that it's a requirement.

if we decide to avoid configuration and just use the default branch, we can use
something like base: context.payload.repository.default_branch

If we can rely on this to get rid of the git ref resoltion code, it seems like a good way to get this forward.

[kipz]

Thanks @jku and @kommendorkapten. I do actually use non-default branches for testing etc, but I don't know how common that is (or would be if it was possible).

I'm not 100% sure what the consensus is here:

1. No branch configuration in action or client, and use the event field context.payload.repository.default_branch in the action, and keep the default branch detection in the client - no defaulting to main whatsoever.
2. As 1, but with configuration to override the default branch in the action and the client.
3. (my current vote): remove the branch detection, default to main, but support overriding in action and client config

My concern with removing the defaulting to main in 1 & 2 is that although it was arguably never the right behavior, it might break some folks who are using main because that's all that is supported, but have a different default branch. In any case, this would be a breaking change.

3. is simple, supports more use cases, and doesn't break the current behavior.

WDYT?