This step supports Conventional Commit formatting and parses the resulting commits into a nicely formatted changelog:
It parses the commit messages by the form:
feat: implemented IAP
-> - Implemented IAP (John Doe)
And if you supply extra context to a Jira ticket or similar:
feat(JRA-123): implemented IAP
-> - JRA-123 Implemented IAP (John Doe)
v1.0.1
-----
🎉 Features
-----
- Implemented IAP (John Doe)
- JRA-123 Implemented IAP (John Doe)
🐛 Bugfixes
-----
- JRA-123 Fixed unintended bug (John Doe)
🤷 Other changes
-----
- Initial commit (John Doe)
It also generates a COMMIT_CHANGELOG_MARKDOWN
which is Github/Slack markdown friendly.
You can override the formatting of each section via the following step inputs:
Step input key | Default value |
---|---|
custom_features_name |
🎉 Features |
custom_bugfixes_name |
🐛 Bugfixes |
custom_maintenance_name |
🔨Improvements |
custom_format_name |
⚒ Formatting |
custom_test_name |
📝 Tests |
custom_refactor_name |
🧹 Refactors |
custom_documentation_name |
📄 Documentation |
custom_other_name |
🤷 Other changes |
Generates a changelog message from git commit for use in other steps. It pulls every commit message between the last two tags or if less than 2 tags are found, all commit messages.
- Cleaned up the code (John Doe)
- Initial commit (John Doe)
Commit messages are pulled via: changelog="$(git log --no-merges --pretty=format:"$prettygitformat" --date=format:"$dateformat" $latest_tag...$previous_tag)"
.
Which enables custom commit message formatting via the step input: pretty_git_format
. Documentation on git log
pretty formats can be found here
You can also override the date format used in git log
via the step input: custom_dateformat
Can be run directly with the bitrise CLI,
just git clone
this repository, cd
into it's folder in your Terminal/Command Line
and call bitrise run test
.
Check the bitrise.yml
file for required inputs which have to be
added to your .bitrise.secrets.yml
file!
Step by step:
- Open up your Terminal / Command Line
git clone
the repositorycd
into the directory of the step (the one you justgit clone
d)- Create a
.bitrise.secrets.yml
file in the same directory ofbitrise.yml
- the.bitrise.secrets.yml
is a git ignored file, you can store your secrets in - Check the
bitrise.yml
file for any secret you should set in.bitrise.secrets.yml
- Best practice is to mark these options with something like
# define these in your .bitrise.secrets.yml
, in theapp:envs
section.
- Once you have all the required secret parameters in your
.bitrise.secrets.yml
you can just run this step with the bitrise CLI:bitrise run test
An example .bitrise.secrets.yml
file:
envs:
- A_SECRET_PARAM_ONE: the value for secret one
- A_SECRET_PARAM_TWO: the value for secret two
- Create a new git repository for your step (don't fork the step template, create a new repository)
- Copy the step template files into your repository
- Fill the
step.sh
with your functionality - Wire out your inputs to
step.yml
(inputs
section) - Fill out the other parts of the
step.yml
too - Provide test values for the inputs in the
bitrise.yml
- Run your step with
bitrise run test
- if it works, you're ready
For Step development guidelines & best practices check this documentation: https://github.com/bitrise-io/bitrise/blob/master/_docs/step-development-guideline.md.
NOTE:
If you want to use your step in your project's bitrise.yml
:
- git push the step into it's repository
- reference it in your
bitrise.yml
with thegit::PUBLIC-GIT-CLONE-URL@BRANCH
step reference style:
- git::https://github.com/user/my-step.git@branch:
title: My step
inputs:
- my_input_1: "my value 1"
- my_input_2: "my value 2"
You can find more examples of step reference styles in the bitrise CLI repository.
- Fork this repository
git clone
it- Create a branch you'll work on
- To use/test the step just follow the How to use this Step section
- Do the changes you want to
- Run/test the step before sending your contribution
- You can also test the step in your
bitrise
project, either on your Mac or on bitrise.io - You just have to replace the step ID in your project's
bitrise.yml
with either a relative path, or with a git URL format - (relative) path format: instead of
- original-step-id:
use- path::./relative/path/of/script/on/your/Mac:
- direct git URL format: instead of
- original-step-id:
use- git::https://github.com/user/step.git@branch:
- You can find more example of alternative step referencing at: https://github.com/bitrise-io/bitrise/blob/master/_examples/tutorials/steps-and-workflows/bitrise.yml
- Once you're done just commit your changes & create a Pull Request
You can share your Step or step version with the bitrise CLI. If you use the bitrise.yml
included in this repository, all you have to do is:
- In your Terminal / Command Line
cd
into this directory (where thebitrise.yml
of the step is located) - Run:
bitrise run test
to test the step - Run:
bitrise run audit-this-step
to audit thestep.yml
- Check the
share-this-step
workflow in thebitrise.yml
, and fill out theenvs
if you haven't done so already (don't forget to bump the version number if this is an update of your step!) - Then run:
bitrise run share-this-step
to share the step (version) you specified in theenvs
- Send the Pull Request, as described in the logs of
bitrise run share-this-step
That's all ;)