inditextech / gh-sherpa Goto Github PK
View Code? Open in Web Editor NEWStreamline branch and pull request creation for Jira or GitHub issues from command line
License: Apache License 2.0
Streamline branch and pull request creation for Jira or GitHub issues from command line
License: Apache License 2.0
When we try to create a PR or branch and the cli prompts us to select the type of branch, if we select the type other, instead of prompting to select among the other types (bugfix, dependency, deprecation, etc), it jumps straight to branch naming and ends up using "other"
as a prefix.
Check this video:
When we select other in the type of branch prompt, it should offer other branch types allow the user to select among them. Like the following screenshot from a previous version of sherpa-cli:
Generate the first release in the repository, so the users can download and install the new binary.
As recommended by OpenSSF Best Pratices, we should give people instructions for reporting security vulnerabilities in your project.
One way is to add a security.md
file: https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
For InditexTech projects, the security.md
file's content is already defined. Check with the OSO (Open Source Office).
Project repository has a security.md file describing the steps to report project's vulnerabilities.
There is a new release of go-gh that covers security update
https://github.com/cli/go-gh/releases/tag/v2.4.0
It's possible to update this dependency?
For ensure that some mandatory files are part of repository we can automate this with repolinter tool, this tool can be automated via github action
Since 24/09/2023 the Survey library we use for user interactivity has been archived and will be no longer maintained.
We could switch to bubbletean.
Currently we have the TLS verification disabled by default, with no way to change it. We should create a configuration to disable it and make it enabled by default.
I don't see a public roadmap for gh-sherpa, isn't bad but having a public roadmap is useful to know what we can expect in new release, when a new release will be published and what features are being developed.
Here you have a roadmap examples:
[PROXMOX] (https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_8.1)
[Opnsense] (https://opnsense.org/about/road-map/)
you can publish a simple markdown file like roadmap.md
Validate the configuration before creating and initializing the services so we can check everything is correct.
Currently it's detected "main"
as a new branch instead of overwriting main
.
main
branch is execute as the default branch.
When I execute
gh extension list
I get back
NAME REPO VERSION
gh sherpa InditexTech/gh-sherpa ad6753cb
Expected behaviour is to get back the extension version in a semVer format, in this case 1.1.0.
Create the configuration file with comments explaining each configurable field.
Create a release workflow that generates the release with a manual trigger.
version
file is updated automatically.Nowadays good security practices are recommended in open source projects, it should be interesting to get the OpenSFF Best Practices Badge, and they have a github action that give us a fabulous sticker
https://www.bestpractices.dev/en/criteria/0
When running the create pr command a second time, it warns that the branch already exists, even when I indicated a different branch name and that's not the case. See example below with "The remote branch already exists, skipping creation...":
โ app-app1 git:(documentation/GH-199-test-docs) gh sherpa cpr -i 199
=> Running create-pr command in Sherpa.
WARNING: there is already a local branch named documentation/GH-199-test-docs for this issue
? Do you want to use this branch to create the pull request No
? Label 'kind/documentation' found. What type of branch name do you want to create? documentation
? Please, write one additional description (optional). Truncate to 22 chars: test-docs-2
A new pull request is going to be created from documentation/GH-199-test-docs-2 to main branch
? Do you want to continue? Yes
The remote branch already exists, skipping creation...
The pull request https://github.com/inditex/app-app1/pull/201 have been created!
You are now working on the branch documentation/GH-199-test-docs-2
Do not warn, as the branch does not exist.
For ensure correct licensing of code reuse is a great tool and it can be automated via github action, following reuse rules we get assurance that our code is perfectly tagged
Add Copyright and LICENSE for each Golang file
// SPDX-FileCopyrightText: 2023 INDITEX S.A
//
// SPDX-License-Identifier: Apache-2.0
If you pass a Pull Request ID as the --issue
flag, it will create another Pull Request.
We should check if the given ID is from a Pull Request or an Issue and force the Issue one.
When given a pull request ID, the CLI should tell the user and stop the execution.
Disable cgo when cross building the distributables so we avoid potential libc6 issues.
Update documentation with up-to-date flow diagrams and new information.
Currently, we are using the kind/dependency
label, but we have not included it in the default labels: https://github.com/InditexTech/gh-sherpa/blob/main/internal/config/default-config.yml#L58
dependency
-> kind/dependency
map is configured in the default config file.Update the dependency for maintenance and fixes.
Remove the "license header per file" approach and move a "directory based" one to prevent file regeneration and improve maintainability.
go
files in the root directory keep the license header.Add Sonar configuration for analyze the code on Sonar Cloud
Currently we don't have the analysis working on the main branch, only the pull requests.
Update the dependency for maintenance and fixes.
Create a configuration section that maps the branch prefixes with specific issue types.
E.g.:
feat/....
bug/...
Note: What happens when there's a collision?
Currently, we are using the kind/internal
label, but we have not included it in the default labels: https://github.com/InditexTech/gh-sherpa/blob/main/internal/config/default-config.yml#L58
internal
-> kind/internal
map is configured in the default config file.Add the appropriated kind/*
label to the pull request so we can use them directly from it.
kind/*
label is assigned in the generated pull requests based on the Jira issue type.Add a release workflow triggering from manual dispatch. This workflow'll responsible for:
Besides that, we need to run Sonar analysis when a pull request is merged to main
branch.
Update to go1.21 so we can use the slices
package in the standard library instead of a dependency.
Follow the best practices from OpenSSF and automate it with GH Actions.
Useful links:
For people from outside gh-sherpa team, we require to sign a CLA (Contributor License Agreement). To request it, we have set up a MS form as first step
In CONTRIBUTING.md file, the first step listed to contribute would be to request signing the CLA filling the attached or linked CLA. If there is any doubt, just ask [email protected]
Currently we don't have a to prioritize GH Sherpa issue types.
In case an issue has several labels associated to several issue types, there should be a way to prioritize one issue type over the others.
One way to achieve this could be creating a new configuration (or inside the current branches
one) so we can provide a way to configure this priority, using (for example) a list:
...
branches:
issue_types_priority: ["bugfix", "feature", "refactoring", "documentation", ...]
Currently we have only one configuration file located in the user's home directory. A better approach would be to create a file hierarchy for each supported operating system, so the users could have different configurations for each projects, with a general one.
This configuration should be merged (instead of replaced) so the users can override some of the configuration options.
Example of hierarchy:
Update the package to the latest compatible version to resolve related vulnerabilities.
The current branch naming validation, which combines the GitHub project name with the branch name, often leads to branch names being unnecessarily short, particularly when the project name is already lengthy. This limitation often limit the ability to put a descriptive name in the branch, making it difficult to adequately convey their purpose or content. To overcome this limitation, it is crucial to provide users with the flexibility to utilize a sufficient number of characters to accurately describe their branches.
Implement a configurable variable that enables users to set the maximum length for branch names. This feature would offer users the flexibility to establish a suitable length, thereby ensuring they possess a satisfactory number of characters to precisely name their branches.
Add the GitHub issue type label to the pull request so we can use it directly from the pull request.
Validate the configuration to avoid side effects when running the application.
mapstructure
WeakType
configurationExtract the interactive (useDefaultValues
) in the root command so we avoid passing it to each sub command
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.