- this can be validated at: `https://gitlab.socs.uoguelph.ca/api/v4/projects/`
1:47 PM - Finished Work
# Sept 20, 2021
9:42 AM - Started Work
## General
- Worked on some coop learning goals (not done yet)
- Read up on CI/CD best practices
- Going to be doing an in depth in Gitlab API, after which, I should have enough knowledge to think of a solution for the branching feature which I see is wanted to be incorperated
- I'm going to link the GitLab API somewhere in our readme. It's necessary to be able to understand the code and how Projects and Groups work
_ I'm basically done planning the route for the incorperation of individual repos into IFS, I just need to finish a rough sketch of the code and begin assigning issues to each necessary function so that development is modular.
## Features
### CI/CD Refurbish
- The current CI/CD process set up for the project is not using best practices.
- We need to modiy out gitlab-ci.yml file.
- All build jobs should be under a `build` stage.
- All test jobs should be under a `test` stage and run only after build stage is successful.
- A deploy stage can be added later for continuous deployment, I just don't know how we would integrate that.
- Tests should be split up into smaller chunks so that we can pinpoint the kind of bugs and errors that may occur.
## Notes
### `ProjectId` Vs `RepoId`
- Currently, `repoId` is being used as the param of the links given as routes.
- What we call `repoId` in out project is called `Project ID` in Gitlab.
- <b>To avoid any confusion for future developers</b>
- it would be best to change all `repoId` variables to a variable called `projectId
### Gitlab API links
-`https://docs.gitlab.com/ee/api/api_resources.html` should be added to our projects documentation somewhere.
### Branching Naming Convention
- We need to develope a branching naming convention that will allow to know what the branch is solving, and maybe even potentaiall what its current state is.
- Master branch should always be production ready.
- Only fully functional branches should be merged into master.
- A branching convention idea?
```
Master A-<name> B-<name> C-<name> D-<name>
|
A1-#1-<name> A2-#2-<name> A3-#3-<name>
|
A1-#1 A2B A2C
```
- A, B, C and D would be the only branches merged into master (once they are funtional)
- These represent a full feature (most likely an epic)
- A1-#1, A2-#2, A3-#3 would be the only branches merged into A (The same goes for B, C and D)
- These represent the full feature (epic) divided into chunks
- Should generally be an isssue
- The #1, #2, #3 etc... is the issue number (issues are given a number when created)
- This number will tell us what issue the branch is trying to solve
- This will ensure that all developers know what issue this branch is trying to solve in case it gets lost in a swamp of created branches by multiple developers
- A2A, A2B, A2C would be the only branches merged into A2
- These represent an issue divided into smaller chunks
- Useful if the issue is devently large and requires multiple functions to be created, then each of these branches can be
- Thesse should <b>only ever be individual tasks that that can be completed with little code</b>
-<b>At no time should there ever be more than 3 layers of branches for a given feature/epic <b/>
- All branches will go through the CI/CD pipe, and, only if they pass build, test and deploy pipes will they be merged.
- The above Example should be documented in a readme in the project (I need to talk with Judi first to see what she thinks)
