sofairofficial/sleppa

Automated release management and package publishing

sleppa's Issues

Refactor configuration management package

Aim

For now, Sleppa configuration crate is not generic.
It loads some value that are defined in structures inside the crate.

In order to be more generic, if a plugin needs a configuration file and/or data, this plugin is in charged to provide a way to load these information.
To implement that, a HashMap and new structure could be used to be more dynamic.

Assumptions

• Three new structure are added : Context, Configuration and Value
• Context is a HashMap<String, Value>
• Configuration is a HashMap<String, Value>
• Value represents all possible type in the Context : String, Commit, User, Tag and release action.
• Each plugin implements its own configuration if needed

Acceptance criteria

• Implements the three new structures
• Provides methods to interact with these structure

Risks

• No specific risk

Dependencies

• No dependencies

References

• figment: a very generic configuration constructor.

Implement features and change version number

Aim

This tasks aims to implement the feature system for Sleppa to implement conditional compilation. The goal is to provide several features :

• default : enables sleppa_primitives, sleppa_commit_analyzer, sleppa_configuration and sleppa_versioner
• changelog: enables sleppa_changelog
• release: enables sleppa_code_archiver
• notify: enables sleppa_notifier

Moreover, the versioning begins with 0.1.0 at the moment. While the crate is semver compatible, the version is provided by the packages uploaded either on GitHub package and crates.io.
Therefore, version on the Sleppa crate must be set at 0.0.0-semver in each Cargo.toml file. The version follows the tag in the GitHub repository.

Assumptions

• The version is given by the tag in the GitHub repository

Acceptance criteria

• Implements the four features
• Sets the version number to 0.0.0-semver in all Cargo.toml file to indicate the crate follows a semantic versioning.
• Sets the version in the main Cargo.toml to 0.0.0-semver, e.g. sleppa_primitives = { version = "0.0.0-semver", path = "crates/sleppa_primitives" }.

Risks

• No risk

Dependencies

• No dependencies

References

• cargo features: features and examples

Design and implement workflow library

Aim

Aim

Assumptions

• assumption

Acceptance criteria

• acceptance

Risks

• No risk

Dependencies

• No dependencies

References

• ref

Implement primitives

Aim

This tasks aims to implement primitives for Sleppa to work.

Assumptions

• The primitives contains all the elements needed for Sleppa to work
• It defines structures, constant, etc. used by multiple crates
• The first structure to implement is a Commit with its three fields : hash, message and type.

Acceptance criteria

• Contains only the convenient primitives, such as, data structures, macros or reusable source code.
• At first, contains at least a Commit structure with its three fields : hash, message and type.

Risks

• No risk

Dependencies

• No dependencies

References

• No reference

Seminal clean up and configuration of the template repository

Aim

This tasks aims to set up and configure the repository.

Assumptions

• None

Acceptance criteria

• The repository is clean
• Files refer to this repository

Risks

• No risk

Dependencies

• No dependencies

References

• No references

Implement release note generator plugin

Aim

This task aims to implement a plugin for Sleppa to generate the CHANGELOG file.
For every release, the file is updated with the new version, the message and the link to the commits it refers.

The changelog is a markdown file and looks like :

To generate this changelog, the path must be described in a toml configuration file. The default path is /changelogs/CHANGELOG.md.
If the file does not exist, a new one is created. If it exists, the new content must be added to this file in a reverse chronological order.

To write the changelog, the commits since the last tag of a repository are given to this crate. Their message will be analyzed to retrieved the type of the commit. Or the sleppa_commit_analyzer is changed to keep this information when parsing their message.

Once the changelog has been written it must be added to the git repository by an automatic commit with a message which looks like Release v3.2.1 where v3.2.1is the new tag of the repository.

Assumptions

• The CHANGELOG file is updated for every release
• It keeps all the change, thus, does not overwrite them.
• The process is similar to semantic-release or Cocogitto

Acceptance criteria

• The CHANGELOG file is a markdown file
• It is updated for every release with notes generator and hyperlink to the commits
• The history is kept
• Reads the given path or set default to /changelogs/CHANGELOG.md
• Automatic commit with message like Release v3.2.1

Risks

• No risk

Dependencies

• No dependencies

References

• Semantic-release changelog
• Cocogitto changelog

Implement configuration file loader

Aim

This tasks aims to implement the configuration file needed for Sleppa to work. This file is mandatory and its name is sleppa.toml.

Assumptions

• This configuration file is close to a .releaserc.json from semantic-release or a cog.toml from Cocogitto

• The file is a toml file

• The file defines exactly 3 release action types : Major, Minor and Patch

• The file is formed like :
  

• The [release_rules] section is mandatory

• For each release action type, a grammar and a format is provided

• Format supports only Peg and Regex

Acceptance criteria

• The configuration loader checks the 3 release action types are provided
• The configuration loader fails if the [release_rules] section is missing

Risks

• No risk

Dependencies

• No dependencies

References

• Semantic-release configuration
• Cocogitto
• TOML
• TOML reader crate: to read the configuration file

Implement sleppa code archiver

Aim

This tasks aims to implement a code archiver which publish a release and its tag to the repository. The archives are a .zip and a .tar.gz format. The tag is formed like v3.2.1.

Assumptions

• Publish the archives for each release.
• Archives are .zip and .tar.gz file's format.
• The new tag must be commited before the release

Acceptance criteria

• Publishes automatically the source code to the repository

Risks

• No risk

Dependencies

• No dependencies

References

• GitHub release
• GitHub API

Implement crates publisher plugin

Aim

This tasks aims to implement a crate publisher into the crates.io website.

Assumptions

• None

Acceptance criteria

• Publishes automatically the package to crates.io

Risks

• No risk

Dependencies

• No dependencies

References

• cargo publish: how to use Cargo to publish on crates.io

Implement commit message parser

Aim

This tasks aims to implement the parser of the commit's message to match the release action type.
As we are running a squash-and-merge strategy for the repository, it must retrieves the pull request's inner commit messages.

Assumptions

• After pull request's inner commit's messages are retrieved, a single release action type must be defined according to the messages. The higher one is kept : major > minor > patch.
• The last tag of the repository is retrieved.
• Only the pull request since the last tag are analyzed. If there is not tag, all the pull request are kept.
• Pull request's name must follow a convention. Our is like Issue to solve (#3) where 3 is the pull request's number.
• If the pull request's name is malformed, it is then ignored.

Acceptance criteria

• Get the last tag of a repository
• Get the pull request since this last tag. If none, all pull request are kept.
• Retrieves the inner commit's messages of the repository pull requests for GitHub
• Analyzes and matches the highest release action type : major > minor > patch

Risks

• No risk

Dependencies

• No dependencies

References

• Sofair commit's type: they are defined in the contributor's bible
• octocrab to send GitHub requests

Implements plugin to notify new release

Aim

This task aims to implement a crate to notify when a new release is published on a collaboration platform such as Mattermost, Slack, Zulip, etc. .

Assumptions

• This crate must be generic to accept any collaboration platform
• It implements a trait Notify to define the general behavior in lib.rs file. This traits contains a method notify_release with a Context and a message as arguments.
• Each platform are implemented as module and provide the trait implementation
• The notification is sent to a specific provided channel, e.g. project-largo-release

Acceptance criteria

• Implements a general trait to define the behavior
• Only Mattermost is implemented at first
• The notification is sent automatically on a provided channel

Risks

• No risk

Dependencies

• No dependencies

References

• Mattermost API
• crate mattermost_api
• crate mattermost_client

Implement versioner plugin

Aim

This tasks aims to implement a versioner for Sleppa. This versioner determines the new tag based on a given release action type.

Assumptions

• The tag is composed of 3 digits, one for each release type and is formed like : v3.2.1 where `v.{major}.{minor}.{patch}
• Each release action type changes the tag differently :
  • major release action increments the first digit by one and set 0 to the others, e.g. v3.2.1 -> v4.0.0
  • minor release action increments the second digit by one and set 0 to the third, e.g. v3.2.1 -> v3.3.0
  • patch release action increments the third digit by one, e.g. v3.2.1 -> v3.2.2

Acceptance criteria

• Creates a new tag structure composed of 3 fields as u64, one field for each release action type digit
• Determines automatically the new tag for a given release action type
• Implements a try_from() function to convert a tag from string to structure

Risks

• No risk

Dependencies

• No dependencies

References