Gitlab Release / Commit Footer References
User Manual
All commit messages must be in conventional commit format and have a footer with a gitlab reference. The reference must be either a merge request or a gitlab issue. (format i.e. !1
or #2
using the correct reference number).
fixing commit messages
If only the last commit is the commit with an error just use git commit --amend
and edit your commit message to be in the correct format and save. now push your changes.
You will require the following information if the commit message with the error is further down the commit tree:
-
Commit message SHA1 of your first commit message to the branch
{original_commit}
-
Commit message SHA1 prior to your first commit
{source_commit}
Run these commands once you have the information above.
Now, navigate to the diff-patches
folder, open up the offending patch (commit) and edit the subject
or message body as appropriate and save. Once all the edits have been done, re-apply the patches to your tree with:
Now push your changes upstream.
:notebook_with_decorative_cover: Note |
---|
As you have changed the commit SHA1(s), when you next push your changes upstream, you must force push. git push --force |
:octagonal_sign: WARNING |
---|
Ensure that all of your commits were exported prior to reseting the branch and when re-applying, that all of your commits were applied correctly |
GitLab CI Template - Developer Manual
Job: gitlab_release
This job bumps the version, updates the changelog, creates a git tag and creates a gitlab release. The git tag and release title use semantic versioning. for this job to function correctly a .cz.yaml
is required in the root of the repository. this file contains the commitizen config and the version details.
Alert
If prior to merging to the master branch you do a version increment, and there are no commits prior to merging. the job will not increment the version and the job will fail. it is recommended that you only do a version increment on the development
branch if you are going to commit further changes to the development
branch
Stage
release
Image
The job uses the registry.gitlab.com/gitlab-org/release-cli:latest
image.
Variables
The job does not use any additional variables.
Explanation
The gitlab_release
job is responsible for creating releases and tags for the GitLab repository. It follows a specific release workflow and utilizes the release-cli
tool to automate the release process.
Steps
-
Set ROOT_DIR variable: Sets the
ROOT_DIR
variable based on the value ofJOB_ROOT_DIR
. -
Create necessary directories: Creates necessary directories for storing artifacts and tests.
-
Install dependencies: Updates the package manager and installs Git and Python 3. Sets up the Python environment by installing required packages.
-
Clone repository: Clones the repository using the provided authentication token and checks out the
development
branch. -
Configure Git: Configures Git settings for the release process.
-
Perform release steps: Executes release-related steps, such as running a custom command (
$MY_COMMAND
), generating the release changelog, and tagging the release. -
Push changes: Pushes the changes to the GitLab repository.
-
Cleanup: Removes the cloned repository.
Rules
-
The job is never triggered when
$JOB_STOP_GITLAB_RELEASE
is true. -
The job is never triggered when the commit author is
nfc_bot <helpdesk@nofusscomputing.com>
. -
If the commit is pushed to the
master
branch, the job is only triggered on successful pipeline execution and failure is not allowed. -
If the commit is pushed to the
development
branch, the job is triggered manually and failure is allowed.
your .gitlab-ci.yml changes
To use this job add the following to your .gitlab-ci.yml
file
CI Job ci commit footer
is automatically set to run on all branches except development
and master
. This job checks the commits on the users branch that they contain a footer with gitlab references. i.e. #1
for issue one or !1
for merge request one.
stages:
- validate
- release
include:
- remote: https://gitlab.com/nofusscomputing/projects/gitlab-ci/-/raw/development/gitlab_release/.gitlab-ci.yml
Gitlab Release:
variables:
MY_COMMAND: "{your command here}"
extends:
- .gitlab_release
if you wish to run any commands you can add them to variable
MY_COMMAND
. The custom command will run under shell/bin/sh
. This command is set to run before the version bump commit is conducted so any changes you wish to add as part of the version bump, you can do here as long as yougit add {changed file name}
.
Job: commit_footer_refs
Stage
validation
Image
The job uses the python:3.6-slim
image.
Variables
DEFAULT_ROOT_DIR
: The default root directory path.
Explanation
The commit_footer_refs
job validates the commit footer references in the GitLab repository. It checks if the commit messages adhere to the conventional commit format and generates a JUnit XML report.
Conventional Commits
Conventional commits follow a specific format for commit messages, consisting of a type, optional scope, and a message. The format is as follows:
-
The
<type>
represents the nature of the changes, such asfeat
for a new feature,fix
for a bug fix,docs
for documentation changes, and so on. -
The
<scope>
(optional) provides additional context for the commit, indicating the module, component, or area of code being modified. -
The
<message>
contains a concise and descriptive summary of the changes.
The commit footer can contain additional information, such as references to issues, feature requests, or pull requests.
Steps
-
Create necessary directories: Creates necessary directories for storing artifacts and test results.
-
Set ROOT_DIR variable: Sets the
ROOT_DIR
variable based on the value ofJOB_ROOT_DIR
. -
Install dependencies: Updates the package manager and installs Git and the required Python packages for the commit footer validation.
-
Clone repository: Clones the repository and checks out the specified branch.
-
Run commit_footer script: Executes the
commit_footer
script to validate the commit footer references. -
Generate artifacts: Generates a JUnit XML report for the test results.
Rules
-
The job is never triggered when
$JOB_STOP_CONVENTIONAL_COMMITS
is true. -
The job is never triggered when
CHANGELOG_FOOTER_REFERENCES
is false. -
The job is always triggered when the commit is not pushed to the master or development branch, and a .cz.yaml file is present, indicating the usage of conventional commits.
-
The job is never triggered otherwise.
Gitlab job Definition
When you include this definition the following makes up the job definition
.gitlab-ci.yml | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 |
|
About:
This page forms part of our Project Gitlab-CI.
Page Metadata
Version: ToDo: place files short git commit hereDate Created: 2021-08-03
Date Edited: 2023-06-10
Contribution:
Would You like to contribute to our Gitlab-CI project? You can assist in the following ways:
- Edit This Page If there is a mistake or a way you can improve it.
- Add a Page to the Manual if you would like to add an item to our manual
- Raise an Issue if there is something about this page you would like to improve, and git is unfamiliar to you.
ToDo: Add the page list of contributors