Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Upkeep minor fix - version bump changes and documentation update #24

Merged
merged 4 commits into from
Oct 21, 2024
Merged

Upkeep minor fix - version bump changes and documentation update #24

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5717143
upkeep-minor-fix: updated the version bump yml to adhere to repo requ…
suneel944 Oct 21, 2024
17686b2
docs: made changes for the contributing and readme docs and defined p…
suneel944 Oct 21, 2024
70f644b
fix: fixed the bug in the version bump and handled the edge cases
suneel944 Oct 21, 2024
d5a9279
docs: updated contributing doc and updated pull request template to a…
suneel944 Oct 21, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 29 additions & 42 deletions .github/pull_request_template.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,48 +1,35 @@
<!--- Provide a general summary of your changes in the Title above -->

## Description
<!--- Describe your changes in detail -->

<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. -->

## Related Issue(s)
<!--- This project only accepts pull requests related to open issues. Please link to the issue here: -->

<!--- If suggesting a new feature or change, please discuss it in an issue first. -->
<!--- If fixing a bug, there should be an issue describing it with steps to reproduce. -->

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->

<!--- If it fixes an open issue, please link to the issue here. -->

## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->

<!--- Include details of your testing environment, and the tests you ran to see how your change affects other areas of the code, etc. -->

## Screenshots (if appropriate):
<!--- Please add screenshots to help explain your changes. -->

## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
<!-- Provide a brief description of the changes in this pull request -->

## Type of change
<!-- Please delete options that are not relevant -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Documentation update (if none of the other choices apply)
- [ ] Other (please describe):
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update

## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->

- [ ] My code follows the code style of this project.
- [ ] I have performed a self-review of my own code.
- [ ] I have commented my code, particularly in hard-to-understand areas.
- [ ] My changes generate no new warnings.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
- [ ] Any dependent changes have been merged and published in downstream modules.
- [ ] The documentation is up-to-date.
## How Has This Been Tested?
<!-- Please describe the tests that you ran to verify your changes -->

<!--- Thank you for contributing to this project! -->
## Checklist:
<!-- Please check off the following items by replacing [ ] with [x] -->
- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream modules

## Conventional Commits
<!-- Please ensure your commit messages follow the Conventional Commits specification -->
- [ ] My commit messages follow the Conventional Commits specification
- [ ] I understand how my commits will affect the version bump (if applicable)

## Additional context
<!-- Add any other context or screenshots about the pull request here -->

## Related Issue
<!-- If applicable, reference the issue number this pull request addresses -->
Fixes #(issue)
65 changes: 56 additions & 9 deletions .github/workflows/version-bump.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,24 +17,50 @@ jobs:
with:
fetch-depth: 0

- name: Check for changes
id: check_changes
run: |
git fetch origin main
changes=$(git diff --name-only origin/main...HEAD | grep -v "uaf/version.py" || true)
if [ -n "$changes" ]; then
echo "has_changes=true" >> $GITHUB_OUTPUT
else
echo "has_changes=false" >> $GITHUB_OUTPUT
fi

- name: Check if last commit is version bump
id: check_last_commit
run: |
last_commit_message=$(git log -1 --pretty=%B)
if [[ $last_commit_message == "chore(release): bump version"* ]]; then
echo "is_version_bump=true" >> $GITHUB_OUTPUT
else
echo "is_version_bump=false" >> $GITHUB_OUTPUT
fi

- name: Get latest version
id: get_version
if: steps.check_changes.outputs.has_changes == 'true' && steps.check_last_commit.outputs.is_version_bump == 'false'
run: echo "version=$(grep -oP '(?<=__version__ = ")[^"]*' uaf/version.py)" >> $GITHUB_OUTPUT

- name: Determine version bump type
id: bump_type
if: steps.check_changes.outputs.has_changes == 'true' && steps.check_last_commit.outputs.is_version_bump == 'false'
run: |
commits=$(git log --pretty=format:"%s" $(git describe --tags --abbrev=0)..HEAD)
if echo "$commits" | grep -qiE "BREAKING CHANGE|major"; then
if echo "$commits" | grep -qiE "BREAKING CHANGE"; then
echo "type=major" >> $GITHUB_OUTPUT
elif echo "$commits" | grep -qiE "feat|feature|minor"; then
elif echo "$commits" | grep -qiE "^feat(\(.+\))?:"; then
echo "type=minor" >> $GITHUB_OUTPUT
else
elif echo "$commits" | grep -qiE "^fix(\(.+\))?:"; then
echo "type=patch" >> $GITHUB_OUTPUT
else
echo "type=none" >> $GITHUB_OUTPUT
fi

- name: Bump version
id: bump_version
if: steps.check_changes.outputs.has_changes == 'true' && steps.check_last_commit.outputs.is_version_bump == 'false' && steps.bump_type.outputs.type != 'none'
run: |
current_version=${{ steps.get_version.outputs.version }}
IFS='.' read -ra version_parts <<< "$current_version"
Expand All @@ -61,10 +87,31 @@ jobs:
echo "new_version=$new_version" >> $GITHUB_OUTPUT
sed -i "s/__version__ = \".*\"/__version__ = \"$new_version\"/" uaf/version.py

- name: Commit and push changes
- name: Generate changelog
id: changelog
if: steps.check_changes.outputs.has_changes == 'true' && steps.check_last_commit.outputs.is_version_bump == 'false'
run: |
changelog=$(git log --pretty=format:"- %s" $(git describe --tags --abbrev=0)..HEAD)
echo "changelog<<EOF" >> $GITHUB_OUTPUT
echo "$changelog" >> $GITHUB_OUTPUT
echo "EOF" >> $GITHUB_OUTPUT

- name: Create Pull Request
uses: peter-evans/create-pull-request@v5
if: steps.check_changes.outputs.has_changes == 'true' && steps.check_last_commit.outputs.is_version_bump == 'false' && steps.bump_type.outputs.type != 'none'
with:
commit-message: "chore(release): bump version to ${{ steps.bump_version.outputs.new_version }}"
title: "Bump version to ${{ steps.bump_version.outputs.new_version }}"
body: |
This PR bumps the version to ${{ steps.bump_version.outputs.new_version }}.

Changes:
${{ steps.changelog.outputs.changelog }}
branch: "version-bump-${{ steps.bump_version.outputs.new_version }}"
delete-branch: true
base: main

- name: No Version Bump Needed
if: steps.bump_type.outputs.type == 'none'
run: |
git config --local user.email "action@github.com"
git config --local user.name "GitHub Action"
git add uaf/version.py
git commit -m "Bump version to ${{ steps.bump_version.outputs.new_version }}"
git push
echo "No version bump needed. Only non-version-changing commits detected."
103 changes: 78 additions & 25 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,45 +1,98 @@
# Contributing Guidelines
# Contributing to This Project

Welcome to the `uaf` project! We appreciate your interest in contributing to our project. Please take a moment to review these guidelines before submitting any contributions.
Thank you for your interest in contributing to our project. To maintain consistency and ensure our automated version bumping works correctly, please follow these guidelines.

## Code of Conduct
## Commit Message Standards

We expect all contributors to follow our [Code of Conduct](CODE_OF_CONDUCT.md) to ensure that the project is a welcoming and inclusive environment for everyone.
We follow the [Conventional Commits](https://www.conventionalcommits.org/) specification for our commit messages. This helps us automatically determine version bumps and generate changelogs.

## Getting Started
### Commit Message Format

To get started with contributing, please follow these steps:
Each commit message should be structured as follows:

1. Fork the `uaf` repository and clone it to your local machine.
2. Create a new branch for your changes: `git checkout -b my-new-branch`.
3. Make your changes and commit them to your branch.
4. Push your changes to your fork: `git push origin my-new-branch`.
5. Open a pull request to the `main` branch of the `uaf` repository.
```
<type>[optional scope]: <description>

## Contribution Guidelines
[optional body]

Before submitting your contributions, please make sure that your changes adhere to the following guidelines:
[optional footer(s)]
```

### Code Style
### Types

We follow the [PEP 8 style guide](https://www.python.org/dev/peps/pep-0008/) for all Python code. Please make sure that your code is formatted and styled according to this guide.
- `feat`: A new feature (triggers a minor version bump)
- `fix`: A bug fix (triggers a patch version bump)
- `docs`: Documentation only changes
- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- `refactor`: A code change that neither fixes a bug nor adds a feature
- `perf`: A code change that improves performance
- `test`: Adding missing tests or correcting existing tests
- `chore`: Changes to the build process or auxiliary tools and libraries such as documentation generation

### Testing
### Breaking Changes

Please make sure that your changes are covered by tests, and that all tests pass before submitting your contribution.
For commits that introduce breaking changes, add `BREAKING CHANGE:` in the commit body or footer. This will trigger a major version bump.

### Documentation
### Examples

Please update the documentation as necessary to reflect your changes.
```
feat: add user authentication feature

### Commit Messages
BREAKING CHANGE: `auth` function now requires an API key
```

Please use clear and descriptive commit messages that explain the purpose of your changes.
```
fix: correct calculation in billing module
```

## Issues and Pull Requests
```
docs: update README with new build instructions
```

If you encounter any issues while contributing, please open an issue in the `uaf` repository. When opening a pull request, please include a brief description of your changes and reference any related issues.
## How This Affects Version Bumping

## License
Our automated version bump process works as follows:

By contributing to the `uaf` project, you agree to license your contributions under the [MIT License](LICENSE).
1. If any commit since the last release contains `BREAKING CHANGE`, the major version is bumped.
2. Otherwise, if any commit contains `feat:`, the minor version is bumped.
3. If neither of the above conditions are met, but there are `fix:` commits, the patch version is bumped.
4. If there are only `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, or `test:` commits, no version bump occurs.

### Multiple Commit Types in a Single Release

When a release includes multiple commit types:

- The highest-priority change determines the version bump (major > minor > patch).
- Commits that don't trigger a version bump (like `chore:`) are included in the release but don't affect the version number.

For example, if you have commits with `feat:`, `fix:`, and `chore:` since the last release, it will result in a minor version bump (due to `feat:`), and all changes (including those from `fix:` and `chore:`) will be included in the release notes.

## Pull Request Process

1. Ensure your commits follow the standards outlined above.
2. Update the README.md or relevant documentation with details of changes, if applicable.
3. Use the pull request template provided when creating your pull request. This template is automatically loaded when you create a new pull request and includes checkboxes for ensuring your contribution meets our standards.
4. Fill out the pull request template completely, checking off each item as you complete it.
5. In the pull request description, provide a clear explanation of the changes and the rationale behind them.
6. If your pull request addresses an existing issue, reference that issue in the pull request description using the syntax `Fixes #123` (where 123 is the issue number).
7. You may merge the Pull Request once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.

## Pull Request Template

When you create a new pull request, you'll see a template with various sections and checkboxes. This template is designed to ensure that your contribution meets our project standards and provides reviewers with all necessary information. Please fill out each section of the template thoroughly.

Key points in the pull request template:

- Describe the type of change (bug fix, new feature, breaking change, etc.)
- Explain how you've tested your changes
- Confirm that you've followed project guidelines (code style, documentation, etc.)
- Verify that your commit messages follow the Conventional Commits specification
- Provide any additional context or screenshots that might be helpful

By using this template, you help maintainers and reviewers understand your contribution more quickly and ensure that all necessary information is provided upfront.

## Questions?

If you have any questions about the contribution process or these standards, please reach out to the project maintainers.

Thank you for helping us maintain a consistent and efficient development process!
13 changes: 12 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -140,7 +140,7 @@ There are two ways in which the framework can be utilised:

- Replace `<envname>` with the environment name, typically 'py'. If Tox is configured for different environments, it might be 'py31xx'.

- When using your preferred IDE, update the interpreter path. Here’s how to do it:
- When using your preferred IDE, update the interpreter path. Here's how to do it:

```bash
which python3
Expand Down Expand Up @@ -231,6 +231,17 @@ There are two ways in which the framework can be utilised:
python cli.py --mode decrypt --key <generated_secret_key> --data_file <relative_file_path>
```

## Contributing

We welcome contributions to this project! Before you start, please read our [CONTRIBUTING.md](CONTRIBUTING.md) file. It contains important information about our development process, coding standards, and how to submit pull requests.

Key points:
- We use [Conventional Commits](https://www.conventionalcommits.org/) for our commit messages.
- Our version bumping is automated based on these commit messages.
- Please ensure your code follows our style guide and passes all tests.

Your contributions help make this project better for everyone. Thank you for your support!

## Running Tests
- Now everything is setup and running fine, one final thing to test if things are really working. To run tests, run the following command

Expand Down