[SECENG-1371] Add GHA JIRA ref check in PR title

[xavigpich]

As part of the audit report Internal Audit: IT Development Governance issued back in May 2023, and in particular recommendation 6.b, we are requested to ensure all GitHub pull requests (PRs) have a linked JIRA ticket to it.

For this reason, we are going to submit a PR to all Ebury repositories creating a GitHub Action that will check there is a JIRA ticket reference on the PR title following format [JIRA_REF] Some additional text. As an example: [SECENG-1111] This is my PR.
See GHA source file for reference.

Note: this means that current branch protections enforcing status checks to pass before merging will block new PRs not following the new formatcomms and ongoing discussion in Slack here.

This PR has been created by a bot owned by Security Engineering. See it here.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
chameleon	⬜️ Ignored (Inspect)	Visit Preview		Jan 22, 2024 3:42pm

[mcibique]

This is a public repo and the workflow is in private repo so it doesn't have a permission to read it. We already had an attempt to do that with Aquasec in the past - it didn't work (see: #1610).

You can see that the workflow fails in this PR as well:

Invalid workflow file: .github/workflows/check-pr-title.yml#L8
error parsing called workflow ".github/workflows/check-pr-title.yml" -> "Ebury/github-tools/.github/workflows/check-pr-title-reusable-workflow.yml@master" : workflow was not found.

[xavigpich]

This is a public repo and the workflow is in private repo so it doesn't have a permission to read it. We already had an attempt to do that with Aquasec in the past - it didn't work (see: #1610).

Makes sense. I've updated with the source GHA file content. We need this to comply with auditors so this ticks the box. We shouldn't expect any updates in the source file anyways.

Let me know what you think

[mcibique]

This is a public repo and the workflow is in private repo so it doesn't have a permission to read it. We already had an attempt to do that with Aquasec in the past - it didn't work (see: #1610).

Makes sense. I've updated with the source GHA file content. We need this to comply with auditors so this ticks the box. We shouldn't expect any updates in the source file anyways.

Let me know what you think

I'm not sure about the meaning of this PR TBH. Do the auditors require a ticket number on non-deployable libraries? Because this project is a library that must be reused somewhere and then deployed to production as a part of the application (in this case it's EBO which enforces ticket numbers). This library can't run on its own, can't be deployed anywhere. It's also weird to enforce ticket numbers on a public project. If we receive a contribution from the public they don't have a JIRA ticket (we don't expect many contribution). It may have an impact on other OSS project we have.

[xavigpich]

It's also weird to enforce ticket numbers on a public project. If we receive a contribution from the public they don't have a JIRA ticket (we don't expect many contribution). It may have an impact on other OSS project we have.

It definitely make sense! I am going to close this PR for now and take it internally for discussion. This is something we will need to bring up on future audits. Thanks again!