Support uppercase repository names with cosign.

[mattmoor]

My previous PR didn't properly handle uppercase usernames (or repository names) when signing container images with cosign.

It seems that the docker buildx --push doesn't like this either, but it's passed the output of the docker/metadata-action which seems to lowercase things.

Fixes: #1293

Signed-off-by: Matt Moore mattmoor@chainguard.dev

thanks to @imjasonh for the suggestion!

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.

---

Tasks

For all workflows, the workflow:

• Should be contained in a .yml file with the language or platform as its filename, in lower, kebab-cased format (for example, docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
• Should use sentence case for the names of workflows and steps (for example, "Run tests").
• Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
• Should include comments in the workflow for any parts that are not obvious or could use clarification.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, ci/properties/docker-publish.properties.json).
• Should run on push to branches: [ $default-branch ] and pull_request to branches: [ $default-branch ].
• Packaging workflows should run on release with types: [ created ].
• Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, docker-publish.yml).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (for example, code-scanning/properties/codeql.properties.json), with properties set as follows:
  • name: Name of the Code Scanning integration.
  • organization: Name of the organization producing the Code Scanning integration.
  • description: Short description of the Code Scanning integration.
  • categories: Array of languages supported by the Code Scanning integration.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.
• Should run on push to branches: [ $default-branch, $protected-branches ] and pull_request to branches: [ $default-branch ]. We also recommend a schedule trigger of cron: $cron-weekly (for example, codeql.yml).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, or
• This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be published to the GitHub Marketplace. We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
• Automation and CI workflows cannot be dependent on a paid service or product.

[mattmoor]

cc @bishal-pdMSFT @jhutchings1

[jhutchings1]

Looks good to me

[bishal-pdMSFT]

Could it be a problem if tags points to a list of tags?

[mattmoor]

Given line 66, I don't think that's possible today, but it could be a problem as folks alter the workflow.

[joshmgross]

👋 Looks like there are some merge conflicts, possibly from the comment change that went with #1295

[mattmoor]

I'll update this shortly

[mattmoor]

Ok, this is rebased!

[github-actions]

This pull request has become stale and will be closed automatically within a period of time. Sorry about that.

[jhutchings1]

@mattmoor Do we still need this change to get merged in? I was surprised to see we never merged it back in December, but I guess holidays got in the way.

[mattmoor]

Yeah, I can rebase it, but it had fallen off my radar. thanks for the ping.

[winstonsmith132]

your welcome Sent from ProtonMail mobile

…

-------- Original Message --------

On Mar. 16, 2022, 12:48 p.m., Matt Moore wrote: Yeah, I can rebase it, but it had fallen off my radar. thanks for the ping. — Reply to this email directly, [view it on GitHub](#1294 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ASADIUN5R5SDHBWXO3LNEZTVAIUITANCNFSM5JPQBQ6Q). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mattmoor]

Just noticed this still on my dashboard. I'm happy to rebase, but it'd be great to coordinate with someone that can merge this to avoid spinning my wheels rebasing 🙏

[Phantsure]

@mattmoor should we go ahead with merge, if there are no changes required?

[mattmoor]

It's been a while, but I'm pretty sure this is good to go. thanks!