A simple GitHub utility to surface details on whats included for a target deployment such as Jira tickets and breaking changes.
It relies on your commit messages being somewhat structured and containing the information that you want to extract. Target data is simply identified using regex. At the moment it is static and supports a couple of default fields from the semantic Git commit tool git-cz. Specifically, it will extract values for Closes: and BREAKING CHANGE:. In the future the plan is to make it tool/format agnostic by allowing you to configure what is important to you.
A user must provide a Github access token that has permissions for the organisation where the repositories live. For a given deployment the user will search and select the desired repositories, and supply target versions for deployment. Using the current and target versions a small report will be generated to highlight whats included.
You can download binaries for your OS from the release section here. MacOS is still to be added.
If you are using linux you will need libgtk3 and libwebkit2gtk-4.0-dev. If you are using a newer version of libwebkit you can build from source following the 'Platform specific dependencies' information here
Before using you must setup a personal access token (PAT) that has access to your organisation. At the moment only organisations are supported. The PAT needs access to content, metadata and repository variables.
Once your token is setup you can start left2deploy and supply your token on the first page. This will safely save your token within your operating system's credential store (keyring, keychain or windows credential manager) for subsequent use.
There is an optional step to setup a repository variable called LAST_DEPLOYED_VERSION. The purpose of this is to hold the last deployed version i.e. the current published version. Left2deploy will use this in the next step to prepopulate the 'Current version' input each time you use the tool, making your life easier.
In order to get the benefits from this setup, your deployment process must update the variable after each successful deployment. The value must be a Git tag.
Now with your access token setup you are ready to start. Simply use the 'Add repo' button to select a new codebase. Using the search, select your desired repository.
There are two fields that must be filled out in order to generate the report. Current version and target version. This is like the 'diff' and its used to determine what's not been deployed for the final report. By default the target version will be prepopulated with the latest tag, and the current version will be prepopulated with the value of the repos LAST_DEPLOYED_VERSION (if setup). The prepopulation is for convienence, the fields can also be changed manually. It's important to note that the fields only accept GitHub tags. There are plans to support commit hashes in the future.
You can repeat the process above for each repository for your deployment. Once complete select the 'Check deployment' button which will generate a small report on what's included.
This is a project that is built using the Wails framework. They have some fantastic documentation on how to get started here. Once you have wails installed along with the system dependencies you should be good to Go!
To run in live development mode, run wails dev in the project directory. This will run a Vite development
server that will provide very fast hot reload of your frontend changes. If you want to develop in a browser
and have access to your Go methods, there is also a dev server that runs on http://localhost:34115. Connect
to this in your browser, and you can call your Go code from devtools.
To create a build manually you can follow the Wails documentation here.
There is a release Github action which is triggered on tag push. It uses wails build command to create binaries for Linux and windows (Mac support later). You can trigger it with the following:
- Create a new tag locally. It must begin with a
v
git tag v1.0.0- Push tag
git push --tags- Verify that a new action has been kicked off on GitHub. Once complete we should have 2 new binaries associated with a GitHub release.
Note: you can use the following tool to help test certain actions locally: act
- Finish MacOS build step from release workflow - need to ensure .app is handled
- Ability to change the 'LAST_DEPLOYED_VERSION' variable name - useful as a repo is likely to deploy to multiple envs. The user should be able to define which one they want per repo/deployment e.g. a variable for dev, staging, prod etc.
- Ability to save deployments - saves the user from typing it each time!
- Harden token handling - avoid holding token in Vue state if possible, move to Go side? (alternativaly could just access keychain/keyring each time its needed)
- Ability to specify a commit hash rather than just a git tag!
- Use wails logger rather than simple prints - https://wails.io/docs/next/reference/runtime/log/
- Add CLI option - Go code can be shared between existing UI and CLI tool, it currently lives in lib.
- Ability to customise whats important i.e. what information/fields to extract from commits messages (rather than default commitizen field names)
- Safety warning that alerts user if a particular repo's commits do not follow your expected shape e.g. don't have required fields that you configure ('Closes', 'Breaking change' etc.)
- Ability to configure deployment report - how the info is displayed, could compliment custom fields to extract
- Dark and light theme toggle