Actions Hooks

This repository houses essential standards, actions, and hooks meticulously crafted to optimize performance for developers

Summary

Words:

• CORNOJOB: Expression used for repetitive manual tasks;

Hooks

Let us customize Git internal behavior and trigger customizable actions at key points in the development life cycle. This command is used by tired/forgotten programmers to run test commands before run a push

Configure it

git config --global core.hooksPath .hooks

Actions

At the folder .github/workflows/ you can find all of the standard actions u'll can add in the project.

jira-create-task

This action runs with the flag you specified for validation. By default, we validate if the string NIT TECDEBT exists in a comment (which could be in a thread). This string was defined by ZRP to identify technical debts based on code reviews. With this in mind, let's automate the 🐮 CORNOJOB 🐮 to read a message and create an issue in the JIRA board with the relevant information.

Before copy/past in your project, add the following secret keys in your repo:

JIRA_BASE_URL, JIRA_USER_EMAIL, JIRA_API_TOKEN

These variables are used to authenticate with Jira's API.

• JIRA_BASE_URL: This is the base URL of your Jira instance. It's usually in the format https://your-domain.atlassian.net.

• JIRA_USER_EMAIL: This is the email address of the user that will be used to authenticate with Jira's API.

• JIRA_API_TOKEN: This is a token generated by Jira that, along with the email address, is used to authenticate with Jira's API.

After all set variables you need set your PROJECT in PROJECT_KEY;

Then you can add a new commit in the PR and be happy with the new issue created in backlog

Templates

In the root of the folder .github/ you can find all of the standard templates u'll can add in the project.

pull_request_template.md

In the .md you can find:

1. Description: This section asks for a summary of the changes made and the related issue. It also asks for any dependencies required for the change. The "Fixes # (issue)" line is a special syntax that, when filled out with an issue number, will automatically close the related issue when the pull request is merged.

2. Type of change: This section asks the contributor to specify the type of change they've made: a bug fix, a new feature, or an enhancement to an existing feature.

3. Testing: This section asks for testing instructions, including the scenarios that are impacted by the changes and any special build instructions.

4. Developer Checklist: This is a list of requirements that the code owner should meet. It includes general requirements, such as appropriate commenting and no console logging, as well as backend-specific requirements, such as securing endpoints and defining interface schemas for new endpoints. There's also a subsection for tests, asking that all existing and new tests pass.

5. Merge Request Review Checklist: This is a list of requirements for the pull request itself. It includes linking the pull request to an issue, testing high-risk workflows, documenting potential enhancements in Jira, and ensuring that dependent changes have been merged and published.

Observations:

Summary: CORNOJOB