gembaadvantage / uplift Goto Github PK

Describe your feature

Uplift currently supports the tagging of repositories and the bumping of files based on the last conventional commit. However, it is missing the ability to generate a changelog, capturing all of the changes between the last 2 tags of a repository.

Initial implementation should just focus on the creation of a changelog between 2 fixed points, i.e. the last 2 tags of a repository

Your potential solution

Add a new changelog command

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

uplift is already being compiled as an ARM binary. To ensure it can be supported on platforms such as AWS Graviton, which is cheaper and faster than AMD64 based Linux, package it within an ARM-based container and publish to both GHCR and DockerHub.

Your potential solution

Modify the existing .goreleaser.yml template to support building a docker container with multiple architectures.

Any additional information?

https://goreleaser.com/customization/docker_manifest/#example-config

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

The uplift readme is getting cluttered and hard to read. Improve the documentation and therefore usability of uplift by moving documentation to a dedicated site.

Your potential solution

Look to use docusaurus to generate documentation for uplift using markdown.

Any additional information?

https://docusaurus.io/

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Provide a way for the uplift config to be validated ahead of time. This will help to ensure a smoother adoption of uplift for new users.

Your potential solution

Extend the existing list of uplift commands to include a config option:

uplift config check

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Goreleaser now has support for automating the publishing of fish food. This was a manual operation previously.

Your potential solution

Extend .goreleaser.yml to include the rigs option for publishing to GoFish

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

When using uplift in certain build scenarios, namely on AWS CodePipeline. It would be useful to check ahead of time whether a release would be carried out by uplift. This would involve just inspecting the latest commit message within the repo and returning a non-zero exit status if a release wouldn't be triggered

Your potential solution

Add a --check flag to the existing release command. No workflow would need to be carried out by uplift. The existing semver package could be used to determine if the commit message would cause a version increment.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

To improve the usability of the changelog generated by uplift, it should embed hyperlinks to tags and commits within the changelog diff

Your potential solution

For this to work, some kind of detection is required to identify what type of git provider is being used. This will enable the correct hyperlinks to be generated.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Add a pull request contributing guide to provide guidance on how to contribute to the Uplift codebase.

Your potential solution

Add a CONTRIBUTING.md to the repository

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Uplift is capable of generating a changelog for every tag that is created on a repository. The diff can contain many different conventional commit messages based on the type of work carried out. Some of these commit messages are prefixed with chore, ci and docs etc. and can prove noisy on a changelog. To allow a user to generate a changelog that is focused on features, bug fixes and breaking changes, for example, certain commit messages should be filtered out

Your potential solution

Add a section to the configuration file that allows a configurable set of filters to control the type of commit messages contained within a changelog diff. The default behaviour should be to include all commit messages.

A possible config could allow the user to configure an includes or an excludes list of commit messages:

changelog:
  includes:
    - feat
    - fix
    - BREAKING CHANGE
    - *!
  excludes:
    - chore(deps)
    - docs
    - ci

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Ensure uplift checks if it is being run within a git repo much earlier in any of its pipelines. This should be carried out once and not duplicated throughout the codebase. It will also make error handling much simpler.

At the moment if an uplift tag is run within a directory that is not a git repository the following error is thrown:

uplift tag
   • latest commit            
Error: fatal: not a git repository (or any of the parent directories): .git

This is just a raw error from git passed back up the error chain. The approach to handling errors needs further work, but is out of the scope of this issue.

Your potential solution

Either introduce a new task that will check if the current directory is a git repository, or make use of cobra lifecycle hooks to inject this check before any commands are executed. The former approach does offer more flexibility.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Ensure that users who download uplift can verify its signature against a public gpg signing key

Your potential solution

Modify the .goreleaser.yml file and sign using a gpg key as per the instructions, https://goreleaser.com/customization/sign/

Any additional information?

No response

Describe your feature

Any snap that is uploaded to Snapcraft by default expects the use of strict confinement:

https://snapcraft.io/docs/snap-confinement

As uplift requires git and changes the files within a users repository, it needs classic confinement. This must be requested on an ad-hoc basis, https://snapcraft.io/docs/reviewing-classic-confinement-snaps

Your potential solution

Raise a request on the Snapcraft forum to request classic confinement for uplift

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

Sorting the changelog behaves differently between the --sort flag and the sort setting within the config file. The --sort flag ignores the case and therefore supports any variant of desc, DESC, asc and ASC.

Setting the sort order through the config file should behave exactly the same.

Steps to reproduce it

1. Create an uplift configuration file and set the changelog sort order to asc
2. Run uplift changelog --diff-only
3. Update the config to now use ASC as the sort order
4. Run uplift changelog --diff-only again and observe that it has switched to the default sort order of desc

Your uplift configuration

changelog:
  sort: ASC

Which version?

v2.4.1

Which operating system(s) are you using?

All

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Provide the option to change the sort order of commits within a changelog entry. By default, everything will be sorted in descending order (newest to oldest commit). Provide the ability to sort in ascending order (oldest to newest commit).

Your potential solution

Add a new setting that will be defaulted to desc, ensuring uplift behaves in exactly the same way. This setting will be exposed through both config and a command-line flag --sort.

changelog:
  # Supports asc | ASC | desc | DESC
  sort: asc

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Allow the commit used by uplift during a release to be customisable. This offers greater flexibility to users when integrating uplift into their CI process.

Your potential solution

Support additional configuration options within the .uplift.yml file:

commit:
  message: an optional customisable message can be provided here
  author: joe.bloggs
  email: [email protected]

Only basic validation is required and uplift should fall back to the default commit message if needed. An author and email must be provided together for uplift to not impersonate the user who initiated the bump

Any additional information?

No response

Describe your feature

Ability to read configuration file from configuration specific folder (.config).

We have a use-case where there are several tools added to the repository and all of these have their specific configuration files. These files will increase the number of files on the repository root, and where some tools support defining non-default configuration locations, others don't. This change could enable cleaner repository structures.

With the small change to the current implementation, configuration files could be iterated from repository root and .config-folder, without changing a lot of the existing functionality.

Your potential solution

On the cmd/uplift/config.go where the possible configuration files are iterated over, nested loop would allow to iterate over several folder options. Following would demonstrate it with root of the repository as well as .config-folder:

var (
	folders = [2]string{"./", ".config"}
	files   = [4]string{".uplift.yml", ".uplift.yaml", "uplift.yml", "uplift.yaml"}
)

func loadConfig() (config.Uplift, error) {
	for _, file := range files {
		for _, folder := range folders {
			cfg, err := config.Load(fmt.Sprintf("%s/%s", folder, file))
			// If the file doesn't exist, try another, until the array is exhausted
			if err != nil && os.IsNotExist(err) {
				continue
			}

			return cfg, err
		}

	}

	return config.Uplift{}, nil
}

Any additional information?

I have forked this repository and opened a pull request on my forked repository towards the fork, but in case this kind of change could be applied to uplift, I could change the Pull Request to point to the original repository.

I have added unit-test changes to my implementation as well.

The Pull Request is here: j-flat#1

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

uplift release currently doesn't provide any way of skipping part of the release workflow. As more features are enabled, it would be more intuitive for a user to be able to skip stages.

Your potential solution

Introduce new flags that allow parts of the workflow to be skipped:

• --skip-changelog: optionally skip the creation or amendment of an existing changelog
• --skip-bumps: optionally skip the bumping of files

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Extend the use of SCM detection within uplift to support Gitea.

Your potential solution

Expand the SCM detection to include checking for Gitea remote URLs. Ensure tag URLs and Commit URLs are also correctly generated for changelog generation.

Any additional information?

https://gitea.io/en-us/

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Add a flag to the changelog command that supports outputting only the changelog diff, rather than creating or appending to an existing CHANGLEOG.md file that may not be required.

Your potential solution

Include an additional flag, something along the lines of --diff-only to change the behaviour of the changelog command to output just the diff to stdout

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

A custom commit message can be provided through the uplift config file. However, only the default commit message will include the next semantic version. By using the $VERSION token as documented, a custom commit message should include the next semantic version if required.

Steps to reproduce it

1. Create an uplift configuration file .uplift.yml
2. Set the commitMessage property to a custom message including the $VERSION token
3. Run uplift: (uplift bump)

Your uplift configuration

commitMessage: chore: a release for $VERSION

Which version?

1.10.2

Which operating system(s) are you using?

Mac

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Provide a mechanism to install the uplift binary without using a package manager. This is useful when using CI services such as AWS CodeBuild

Your potential solution

Create a shell script that can be used to download the binary from Github and install into the required location for execution

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Add a flag to the tag command that supports the output of the next git tag without tagging and pushing back to the remote. This allows the tag to be captured within a user script and processed in a different way.

Your potential solution

Add a new flag to the tag command, something like --next which will output the next calculated tag to stdout. As logging through apex is to stderr by default, a simple write to stdout should be sufficient. Especially when coupled with the new --silent flag

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Uplift at the moment performs both up versioning of files and tagging of the repository in one atomic operation. There are scenarios where this may not be the desired output and tagging the repository may want to be carried out in isolation.

Your potential solution

A new tag command should be offered to the caller. This will simply bump the tag against the current commit within the repository.

uplift tag

The same --dry-run and --verbose flags should be supported.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

If introducing uplift to an already established project there isn't an option of generating a changelog for its complete history. Currently uplift will either create a changelog for the first tag on a new project, or the diff between 2 tags when processing a new release.

Your potential solution

Add an additional --all flag to the changelog command to support the creation of a complete changelog.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Request a domain for uplift in preparation for creating a dedicated website

Your potential solution

Register a new domain

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

upilft fails to generate a changelog for a CodeCommit repository that has been checked out using the GRC protocol.

uplift changelog --all --dry-run
   • latest commit            
      • retrieved latest commit   author=******* email=*********** message=ci: update to existing workflow
   • next commit              
      • changes will be committed with email=*********** message=ci(uplift): uplifted for version  name=*******
   • detect scm               
      • failed to identify scm provider of repository
Error: malformed repository URL: codecommit::eu-west-1://<AWS_PROFILE>@<REPOSITORY>

Steps to reproduce it

1. clone a repository from AWS CodeCommit using the codecommit:// protocol
2. run uplift changelog --all --dry-run

Your uplift configuration

No response

Which version?

2.1.0

Which operating system(s) are you using?

All

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Ensure the CLI documentation when accessed from the terminal is on par with the new online documentation being generated. This will greatly improve the experience of using uplift.

Your potential solution

Cobra provides this functionality, so it should be pretty straightforward to expand the existing CLI documentation through:

• Short descriptions
• Long descriptions
• Examples

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Tasks should support skipping to prevent unnecessary execution.

For example, if tagging a repository, it makes no sense to perform further tasks if the identified conventional commit signals no version change:

$ uplift tag

• current version
  • identified version        current=v0.26.0
• next version
  • no change in version needed commit=chore: update the readme
• next commit
  • committing with           email=***** message=ci(bump): bumped version to v0.26.0 name=*****
• tag
  • no version change detected current=v0.26.0 next=v0.26.0

Your potential solution

Add a Skip() function to the task definition and inspect its value before executing it

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Uplift has recently been published as a docker container, but needs to be tested against the top CI providers, to ensure it can be offered as a potential solution.

List of current identified providers:

• - Circle CI
• - Drone
• - GitLab
• - Semaphore CI
• - Travis CI
• - Cirrus CI
• - Azure
• - Google CloudBuild
• - AWS CodeBuild
• - AWS CodePipeline
• - Codefresh

Uplift will no doubt required permissions on these providers to modify and push changes back to any cloned repository.

Your potential solution

Test uplift on all of the mentioned CI providers and determine what changes, if any, are needed to ensure uplift can run on those providers. Create new issues per provider if required.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

uplift will generate a custom commit message when performing a bump or release command. This auto-generated message then pollutes the changelog history and has to be manually ignored.

Your potential solution

Add a default exclude to the changelog filters that will automatically remove any commit prefixed with ci(uplift):

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

When calculating a changelog diff using uplift changelog --diff-only SCM detection is being ignored and the changelog output is incorrect

Steps to reproduce it

Run `uplift changelog --diff-only` against a repository that is currently supported for SCM detection, for example GitHub

Your uplift configuration

No response

Which version?

v2.4.0

Which operating system(s) are you using?

All

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

File bumping only supports version detection through regular expressions at present. This works as a nice catch-all mechanism for custom file types within a repository. However, when dealing with JSON files, it would be much simpler (and provide a better developer experience) to support the use of JSON paths to locate and replace a version.

Your potential solution

Expand the existing config to support the inclusion of a JSON path(s) when defining a bump.

bumps:
  - 
    file: ./package.json
    json: 
      - path: 'version'
      - path: 'some-key.something.version'

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Uplift was initially designed for a workflow of small frequent commits where each would be delivered to production through continuous delivery/deployment. However, this does overlook any form of pre-releasing strategy, making uplift not suitable for many other types of workflow.

Improve the versatility of uplift by extending it to support a user's pre-release strategy.

Your potential solution

Extend the existing uplift commands to include a new flag --prerelease (or something similar) that allows a user to define a pre-release suffix that will be appended to the calculated semantic version. The final version must be semver compliant.

As this is more of an ad-hoc operation, it won't be included as a config option.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

The changelog outputted from Uplift is not correctly formatted. Commits should be outputted in a bulleted list, otherwise, commits are condensed into a single line.

Running command uplift changelog --diff-only for example:

## [2.3.5] - 2022-01-20

e988091 fix: this is another commit
11d039b fix: this is another commit
fad2c38 fix: this is another commit

It should be generated as:

## [2.3.5] - 2022-01-20

- e988091 fix: this is another commit
- 11d039b fix: this is another commit
- fad2c38 fix: this is another commit

Steps to reproduce it

uplift changelog --diff-only

Your uplift configuration

No response

Which version?

1.12.0

Which operating system(s) are you using?

Mac

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

uplift supports the bumping of files by using regex pattern matching. However, the config is designed to only match the version in a single place, which may not always be true with all file types. The current solution would require multiple definitions for the same file, which is not that practical.

Your potential solution

Extend the config to support multiple regex definitions for a single file:

bumps:
  - file: ./Chart.yaml
    regex:
      - pattern: "version: $VERSION"
        count: 1
        semver: true
      - pattern: "appVersion: $VERSION"
        count: 1

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

If I first run the bump script it will create a commit like "ci(bump): bumped version to v1.1.4" and then it will run the tag script but it will responde with "no change in version needed commit=ci(bump): bumped version to v1.1.4" so the commit never gets a tag.

Steps to reproduce it

1. run uplift bump
2. run uplift tag

Your uplift configuration

firstVersion: v1.0.0
annotatedTags: false

commitAuthor:
  name: "..."
  email: "..."
bumps:
  - # The path of the file relative to where uplift is executed
    file: ./pubspec.yaml
    regex: "version: $VERSION"
    semver: true

Which version?

1.2.0

Which operating system(s) are you using?

Linux, Windows

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Add an additional CLI operation that will perform a release. A release will allow multiple operations to be executed automatically. An example being a bump, followed by a tag of that associated commit.is

Your potential solution

Add a new release option to the existing CLI

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Uplift can be quite noisy when running, as it outputs details about every step of the process, which is useful when being run within a CI pipeline for example. However, it has changed quite a lot from its initial inception and now supports a multitude of commands that run in isolation. The reason behind this was to allow uplift to be run as part of a scripted process, without it having to control the entire release process.

Silencing the output will allow uplift to be more user friendly when running in that scripted scenario.

Your potential solution

Add a new --silent flag that silences all output through the apex logging framework. This can be achieved by passing in a handler to apex that effectively ignores all logging

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

uplift can detect if a repository has been cloned from GitHub or GitLab, but only their cloud services. If running against a self-hosted enterprise instance, SCM detection will not be successful.

Your potential solution

Extend the uplift config to include a section for configuring how SCM detection works against a self-hosted instance of GitHub and GitLab.

Config to be decided.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

To improve the usability of uplift, bash auto-completion scripts should be created for the bash, zsh and fish shells.

Your potential solution

Cobra provides this functionality and should be exposed as an additional option. https://github.com/spf13/cobra/blob/master/shell_completions.md

Any additional information?

No response

Describe your feature

By default, uplift is designed to carry out a semantic release based on the latest conventional commit message. However, there may be times when pushing changes back to a remote should be carried out by a user. For example, migrating an existing repository to use a changelog format that is managed by uplift.

Your potential solution

Add a global flag --no-push that disables git push functionality within uplift for any commands that support it

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

The mechanism uplift uses for identifying the latest tag requires additional work to support better filtering of transient tags. Currently, if any tags such as v1 or prod are used, they are correctly ignored. However, if a tag in the following pattern is used *.*.* it will be incorrectly retrieved and parsed as a semantic version, which can result in uplift using the default (or configured) first release semantic version.

Steps to reproduce it

1. init a new repository and create a few commits and tags e.g. 0.1.0, 0.2.0
2. add a commit and tag the repository with a tag that matches the pattern *.*.* e.g. a.b.c
3. run uplift tag --next
3. uplift will select the next tag as 0.1.0

Your uplift configuration

No response

Which version?

v2.4.2

Which operating system(s) are you using?

All

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Currently uplift only supports lightweight tags. These are effectively just a pointer to a commit at a certain point in time and are seen as temporary tags. Annotated tags are stored as full objects within the git database and support the following features:

1. Tagger details (name, email etc)
2. GPG signed tags

Your potential solution

Support the options of lightweight/annotated tags within the uplift config YAML file

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Uplift has been building and publishing a docker container for the last couple of releases, but unfortunately has not included any documentation on how that docker image can be pulled and used correctly

Your potential solution

Update documentation on GH Pages and DockerHub with instructions on using uplift correctly.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Publish the built uplift binaries to snapcraft

Your potential solution

Update the goreleaser definition within the repository to support the publishing of uplift binaries to snapcraft, see: https://goreleaser.com/customization/snapcraft/

Any additional information?

No response

What happened?

When generating a changelog, the current header is:

# Changelog

All notable changes to this project will be documented in this file.

Which doesn't align with the keep a changelog specification:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

Steps to reproduce it

uplift changelog

Your uplift configuration

No response

Which version?

1.10.0

Which operating system(s) are you using?

Mac

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

File bumping only supports version detection through regular expressions at present. This works as a nice catch-all mechanism for custom file types within a repository. However, when dealing with YAML files, it would be much simpler (and provide a better developer experience) to support the use of YAML paths to locate and replace a version.

Your potential solution

Expand the existing config to support the inclusion of a YAML path(s) when defining a bump.

bumps:
  - 
    file: ./Chart.yaml
    yaml: 
       - path: 'version'
         semver: true
       - path: 'appVersion'

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

The usage of uplift can be simplified by providing a docker image that can be used directly within CI tooling. Most CI tooling provides the option of running against a user-defined base image. This saves having to download and manage uplift separately.

Your potential solution

Write a Dockerfile and include Docker image creation within the release process.

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

What happened?

The output from the release check isn't very informative and doesn't match the format used by other commands.

Steps to reproduce it

$ uplift release check
Error: no release will be triggered

Your uplift configuration

No response

Which version?

1.10.1

Which operating system(s) are you using?

Mac

Optional debug output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Describe your feature

Uplift can perform a release against a repository that currently bumps files and tags a repository using the latest calculated semantic version. Changelog generation is included as a separate command and should also be incorporated within the release workflow.

Your potential solution

Wire the changelog task into the existing release workflow

Any additional information?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct