Continuous integration workflow

[julianramirez2]

Description

The "Continuous Integration" file was created for the CI Workflow, which generates releases based on the "Conventional Commits" syntax. Additionally, this workflow handles version management, ensuring that the version of the plugin is updated in both the main plugin file and the README.txt file based on each release.

Finally, the changes for each release will be written to the CHANGELOG file to maintain a comprehensive history of all modifications corresponding to each version.

In addition to this, the coverage file is removed since the unit-testing workflow takes care of performing this test, making it redundant and unnecessary to have a separate YML file for this task. The SVN workflow file is also removed because it is not currently being used, and we want to keep the repository clean.

Testing instructions

The best way to perform testing is to take the code within the .github/workflows/continuous-integration.yml file and create a branch and/or fork. You can then modify lines 5 and 17 of the file to specify the branch name where you want the releases to be generated. Depending on whether you push changes to the branch or perform commits/merges from other branches, the workflow will be triggered to launch a new release.

Here are the steps you can follow:

• Create a branch or fork of the repository where the .github/workflows/continuous-integration.yml file is located.
• Open the file and locate lines 5 and 17.
• Modify line 5 to specify the branch name you want to use for generating releases.
• Similarly, modify line 17 to match the desired branch name.
• Save the changes to the file.
• Make any necessary changes or add new code to the branch.
• Commit and push the changes to the branch.
• The CI workflow will be triggered automatically, and it will generate a new release based on the specified branch name.
• Review the release and verify that it meets the desired criteria and includes the intended changes.
• Repeat the process by making additional changes or merging branches to trigger new releases as needed.

Checklist for Merge

• Tested in a remote environment
• Updated documentation
• Rebased master/main
• Squashed commits

[MaferMazu]

This looks good to me. Please remember to squash and merge, and take care of the name of the final commit because I think it takes the name of the PR by default, which does not follow the conventional commits.