ci: set git committer email in the semantic release jobs

Jaime Martinezrequested to merge
ci-set-commiter-email-address into master

What does this MR do?

I tried to run the cut release job but got the error:

  stderr: "remote: GitLab: You cannot push commits for 'semantic-release-bot@martynus.net'. You can only push commits if the committer email is one of your own verified emails.\n" +
    'To https://gitlab.com/gitlab-org/container-registry.git\n' +
    ' ! [remote rejected]   HEAD -> master (pre-receive hook declined)\n' +
    "error: failed to push some refs to 'https://gitlab.com/gitlab-org/container-registry.git'",

Searching for the error I got to two places:

So I got the token value and queried the API /api/v4/user to get the email address.

I've now setup the $GITLAB_TOKEN_EMAIL environment variable in the project settings, so we can try creating the release via the cut job again 🤞

Author checklist

  • Feature flags
    • Added feature flag:
    • This feature does not require a feature flag
  • I added unit tests or they are not required
  • I added documentation (or it's not required)
  • I followed code review guidelines
  • I followed Go Style guidelines
  • For database changes including schema migrations:
    • Manually run up and down migrations in a postgres.ai production database clone and post a screenshot of the result here.
    • If adding new queries, extract a query plan from postgres.ai and post the link here. If changing existing queries, also extract a query plan for the current version for comparison.
    • Do not include code that depends on the schema migrations in the same commit. Split the MR into two or more.
  • Ensured this change is safe to deploy to individual stages in the same environment (cny -> prod). State-related changes can be troublesome due to having parts of the fleet processing (possibly related) requests in different ways.

Reviewer checklist

  • Ensure the commit and MR tittle are still accurate.
  • If the change contains a breaking change, apply the breaking change label.
  • If the change is considered high risk, apply the label high-risk-change
  • Identify if the change can be rolled back safely. (note: all other reasons for not being able to rollback will be sufficiently captured by major version changes).

If the MR introduces database schema migrations:

  • Ensure the commit and MR tittle start with fix:, feat:, or perf: so that the change appears on the Changelog
If the changes cannot be rolled back follow these steps:
  • If not, apply the label cannot-rollback.
  • Add a section to the MR description that includes the following details:
    • The reasoning behind why a release containing the presented MR can not be rolled back (e.g. schema migrations or changes to the FS structure)
    • Detailed steps to revert/disable a feature introduced by the same change where a migration cannot be rolled back. (note: ideally MRs containing schema migrations should not contain feature changes.)
    • Ensure this MR does not add code that depends on these changes that cannot be rolled back.

Merge request reports