ladder99
ladder99 copied to clipboard
Define a GitHub workflow
We need to clearly define our Github workflow (issues, projects, milestones, branches, versioning …).
This issue should be considered a meta-issue and sub-issues should be created when needed for individual parts of this issues.
Related GitHub docs:
- Creating and editing milestones for issues and pull requests;
- Best practices for Projects;
- About Projects;
- About milestones.
Questions to ask:
-
[ ] What is the lifecycle of a problem/task?
- Create an issue where we describe everything related, let everything comment on it. Use task lists in the issue description if the issue is a bit larger, however, strive to make one issue a single problem. In case an issue is a meta-issue, make the tasks in the task list link to other issues where we should discuss the details about a particular task.
- Don’t forget to assigne lables, milestones, projects, assignees.
- Make a decision on how to implement it. The decision could change multiple times during implementation and the issue description should change accordingly.
- Implement it in a fork, ideally in a feature branch.
- Create a pull request.
- GitHub Actions should run some checks and tests.
- Let others review our changes, test the code, comment on the code in the PR.
- Let others approve your change if it is looking good.
- Merge it to the default branch.
-
[ ] What will be our milestones? Release milestones? Feature milestones? Both?
-
[ ] How exactly we will use projects?
-
[ ] What versioning do we use? SemVer? Could we use the same version for all apps and libs?
- Currently, each microservice seems to be versioned separately:
# `version` value in `package.json` of each app (microservice) services/meter/package.json : 0.1.0 services/recorder/package.json : 0.1.0 services/adapter/package.json : 0.10.1 services/relay/package.json : 0.10.1 services/simulator/package.json : 0.1.0 services/compiler/package.json : 0.1.0
-
[ ] Use GitHub Releases to publish our releases.