Compare commits
No commits in common. "51ff1f0d13b6f5efcdad457ae54ab4db37412854" and "df48572e4a3e1c58fdcee1c7dd145947c9b40e56" have entirely different histories.
51ff1f0d13
...
df48572e4a
29
.gitignore
vendored
29
.gitignore
vendored
@ -1,29 +0,0 @@
|
|||||||
# Dependencies
|
|
||||||
/node_modules
|
|
||||||
|
|
||||||
# Testing
|
|
||||||
/coverage
|
|
||||||
|
|
||||||
# Production
|
|
||||||
/build
|
|
||||||
/dist
|
|
||||||
|
|
||||||
# Misc
|
|
||||||
.DS_Store
|
|
||||||
.env.local
|
|
||||||
.env.development.local
|
|
||||||
.env.test.local
|
|
||||||
.env.production.local
|
|
||||||
|
|
||||||
# Debug logs
|
|
||||||
npm-debug.log*
|
|
||||||
|
|
||||||
# IDE
|
|
||||||
.idea/
|
|
||||||
.vscode/
|
|
||||||
*.swp
|
|
||||||
*.swo
|
|
||||||
|
|
||||||
# Docusaurus
|
|
||||||
.docusaurus
|
|
||||||
.cache
|
|
||||||
@ -1,106 +0,0 @@
|
|||||||
---
|
|
||||||
id: 01-overview
|
|
||||||
title: Overview
|
|
||||||
---
|
|
||||||
|
|
||||||
# Overview
|
|
||||||
|
|
||||||
## Purpose
|
|
||||||
This document provides comprehensive information about our development workflow, including GitFlow workflow management, CI/CD pipeline integration with Jenkins, Gitea repository management, release processes, and detailed setup instructions for all components. It serves as the central reference for developers to understand and implement our standardized development practices and workflows.
|
|
||||||
|
|
||||||
## Document Structure
|
|
||||||
The development workflow documentation is organized into the following main sections:
|
|
||||||
|
|
||||||
### 1. **GitFlow Workflow**
|
|
||||||
- Branching strategy and naming conventions
|
|
||||||
- Feature, develop, release, and hotfix branch workflows
|
|
||||||
- Pull request and code review processes
|
|
||||||
- Merge strategies and conflict resolution
|
|
||||||
|
|
||||||
### 2. **Gitea Management**
|
|
||||||
- Repository setup and configuration
|
|
||||||
- User and team management
|
|
||||||
- Access control and permissions
|
|
||||||
- Webhook configuration for CI/CD integration
|
|
||||||
- Gitea Actions setup and configuration
|
|
||||||
|
|
||||||
### 3. **Jenkins CI/CD Pipeline**
|
|
||||||
- Jenkins server setup and configuration
|
|
||||||
- Pipeline job definitions and configurations
|
|
||||||
- Build, test, and deployment automation
|
|
||||||
- Integration with Gitea and other tools
|
|
||||||
- Monitoring and notification systems
|
|
||||||
|
|
||||||
### 4. **Release Management**
|
|
||||||
- Release planning and versioning strategy
|
|
||||||
- Release branch creation and management
|
|
||||||
- Deployment procedures and environments
|
|
||||||
- Rollback strategies and emergency procedures
|
|
||||||
- Release notes and documentation
|
|
||||||
|
|
||||||
### 5. **Setup and Configuration**
|
|
||||||
- Step-by-step setup instructions for Gitea
|
|
||||||
- Jenkins installation and configuration
|
|
||||||
- Gitea Actions setup and workflow configuration
|
|
||||||
- Environment-specific configurations
|
|
||||||
- Troubleshooting guides and common issues
|
|
||||||
|
|
||||||
## Key Workflow Components
|
|
||||||
|
|
||||||
### Development Cycle
|
|
||||||
1. **Feature Development**: Create feature branches from develop
|
|
||||||
2. **Code Review**: Submit pull requests for review and approval
|
|
||||||
3. **Integration**: Merge approved features into develop branch
|
|
||||||
4. **Release Preparation**: Create release branches from develop
|
|
||||||
5. **Testing & Deployment**: Automated testing and deployment via Jenkins
|
|
||||||
6. **Release**: Merge release branches to master and develop
|
|
||||||
7. **Hotfixes**: Emergency fixes directly from master branch
|
|
||||||
|
|
||||||
### Automation Benefits
|
|
||||||
- **Continuous Integration**: Automated builds and testing on every commit
|
|
||||||
- **Quality Gates**: Automated code quality checks and security scans
|
|
||||||
- **Deployment Automation**: Consistent and repeatable deployment processes
|
|
||||||
- **Monitoring**: Real-time feedback on build and deployment status
|
|
||||||
|
|
||||||
## How to Use This Documentation
|
|
||||||
|
|
||||||
### For Developers
|
|
||||||
- Follow the GitFlow workflow for all code changes
|
|
||||||
- Use the setup guides to configure your local development environment
|
|
||||||
- Reference the release procedures when preparing for releases
|
|
||||||
- Check troubleshooting guides for common issues
|
|
||||||
- Understand how your code changes trigger CI/CD pipelines
|
|
||||||
- Learn how to work with Gitea repositories and pull requests
|
|
||||||
- Familiarize yourself with release processes and versioning
|
|
||||||
|
|
||||||
## Contributing to Workflow Documentation
|
|
||||||
|
|
||||||
To contribute improvements or updates to the workflow documentation:
|
|
||||||
|
|
||||||
1. Clone the repository: `git clone [repository-url]`
|
|
||||||
2. Create a feature branch: `git checkout -b feature/workflow-improvement`
|
|
||||||
3. Make your changes following the established documentation structure
|
|
||||||
4. Ensure all setup instructions are tested and verified
|
|
||||||
5. Commit and push your changes with descriptive commit messages
|
|
||||||
6. Open a Pull Request with detailed description of changes
|
|
||||||
7. Request review from relevant team members
|
|
||||||
|
|
||||||
:::note
|
|
||||||
Please ensure all workflow changes are tested in a staging environment before updating production documentation.
|
|
||||||
:::
|
|
||||||
|
|
||||||
:::tip
|
|
||||||
Keep documentation up-to-date with actual workflow implementations. Outdated documentation can cause confusion and workflow issues.
|
|
||||||
:::
|
|
||||||
|
|
||||||
## Getting Started
|
|
||||||
|
|
||||||
If you're new to our development workflow:
|
|
||||||
|
|
||||||
1. Start with the **GitFlow Workflow** section to understand our branching strategy
|
|
||||||
2. Review **Gitea Management** for repository access and permissions
|
|
||||||
3. Check **Jenkins Setup** for CI/CD pipeline understanding
|
|
||||||
4. Familiarize yourself with **Release Management** procedures
|
|
||||||
5. Use **Setup Guides** to configure your development environment
|
|
||||||
|
|
||||||
For immediate assistance, contact the DevOps team or refer to the troubleshooting sections in each component's documentation.
|
|
||||||
@ -1,324 +0,0 @@
|
|||||||
---
|
|
||||||
id: 02-gitflow
|
|
||||||
title: Gitflow
|
|
||||||
---
|
|
||||||
|
|
||||||
## **Overview**
|
|
||||||
|
|
||||||
Gitflow is really just an abstract idea of a Git workflow. This means it dictates what kind of branches to set up and how to merge them together. We will touch on the purposes of the branches below.
|
|
||||||
|
|
||||||
## **Branches**
|
|
||||||
|
|
||||||
### 1️⃣ Master Branch
|
|
||||||
|
|
||||||
The `master` branch represents the **LIVE environment**. It always contains the latest stable code that has been fully tested and approved for deployment.
|
|
||||||
|
|
||||||
- Any changes to the `master` branch must go through a **pull request**.
|
|
||||||
- **Team Leaders** are responsible for reviewing and merging approved changes.
|
|
||||||
|
|
||||||
This ensures the `master` branch remains a **single source of truth** for the production system.
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
---
|
|
||||||
config:
|
|
||||||
theme: 'base'
|
|
||||||
gitGraph:
|
|
||||||
mainBranchName: 'master'
|
|
||||||
showCommitLabel: false
|
|
||||||
---
|
|
||||||
gitGraph
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
branch release
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
commit tag: "v1 (SAT)"
|
|
||||||
checkout master
|
|
||||||
merge release tag: "LIVE v1"
|
|
||||||
checkout release
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
commit tag: "v2 (SAT)"
|
|
||||||
checkout master
|
|
||||||
merge release tag: "LIVE v2"
|
|
||||||
```
|
|
||||||
|
|
||||||
### 2️⃣ Release Branch
|
|
||||||
|
|
||||||
The release branch serves as the **staging ground for production-ready code**. It contains all features and fixes that have passed internal testing and are being prepared for deployment.
|
|
||||||
|
|
||||||
- A **SAT**[^1] version will be created from the `release` branch and tagged with a version number.
|
|
||||||
- Once the SAT build is approved and deployed to **LIVE**, the confirmed version will be merged into the `master` branch.
|
|
||||||
- Any changes to the `master` branch must go through a **pull request**.
|
|
||||||
- **Team Leaders** are responsible for reviewing and merging approved changes.
|
|
||||||
|
|
||||||
This workflow ensures that only validated and stable code reaches production.
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
---
|
|
||||||
config:
|
|
||||||
theme: 'base'
|
|
||||||
gitGraph:
|
|
||||||
mainBranchName: 'master'
|
|
||||||
showCommitLabel: false
|
|
||||||
---
|
|
||||||
gitGraph
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
branch release
|
|
||||||
branch develop
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v1 (SAT)"
|
|
||||||
checkout master
|
|
||||||
merge release tag: "LIVE v1"
|
|
||||||
checkout develop
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v2 (SAT)"
|
|
||||||
checkout master
|
|
||||||
merge release tag: "LIVE v2"
|
|
||||||
```
|
|
||||||
|
|
||||||
### 3️⃣ Develop Branch
|
|
||||||
|
|
||||||
The `develop` branch is the main integration branch where **all features**, **enhancements**, and **bug fixes** are combined. It contains the complete history of the project’s ongoing development.
|
|
||||||
|
|
||||||
- **Feature** branches and **bugfix** branches must be merged into develop through pull requests.
|
|
||||||
- **Team Leaders** are responsible for reviewing and approving merges.
|
|
||||||
- Once development is stable and ready for validation, `develop` is merged into the `release` branch, where a **SAT** version will be created and tagged.
|
|
||||||
|
|
||||||
This workflow ensures that `develop` is always the latest working version, but not necessarily production-ready.
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
---
|
|
||||||
config:
|
|
||||||
theme: 'base'
|
|
||||||
gitGraph:
|
|
||||||
mainBranchName: 'master'
|
|
||||||
showCommitLabel: false
|
|
||||||
---
|
|
||||||
gitGraph
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
branch release
|
|
||||||
branch develop
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v1 (SAT)"
|
|
||||||
checkout master
|
|
||||||
merge release tag: "LIVE v1"
|
|
||||||
checkout develop
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v2 (SAT)"
|
|
||||||
checkout master
|
|
||||||
merge release tag: "LIVE v2"
|
|
||||||
checkout develop
|
|
||||||
commit
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4️⃣ Feature branches
|
|
||||||
|
|
||||||
Feature branches are used to **develop new functionality in isolation** from the main integration and production branches. This ensures stability and prevents incomplete features from affecting the project’s main workflow.
|
|
||||||
|
|
||||||
- Each new feature must be developed in its own branch.
|
|
||||||
- Feature branches are always created from the latest `develop` branch.
|
|
||||||
- Once complete, the feature must be merged back into `develop` via a **pull request**.
|
|
||||||
- **Team Leaders** are responsible for reviewing and approving feature branch merges.
|
|
||||||
- Feature branches must never interact directly with the `master` branch or the `release` branch.
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
---
|
|
||||||
config:
|
|
||||||
theme: 'base'
|
|
||||||
gitGraph:
|
|
||||||
mainBranchName: 'release'
|
|
||||||
showCommitLabel: false
|
|
||||||
---
|
|
||||||
gitGraph
|
|
||||||
commit
|
|
||||||
branch develop
|
|
||||||
commit
|
|
||||||
branch feature/feature-a
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout develop
|
|
||||||
merge feature/feature-a
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v1 (SAT)"
|
|
||||||
checkout develop
|
|
||||||
branch feature/feature-b
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout develop
|
|
||||||
branch feature/feature-c
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout develop
|
|
||||||
merge feature/feature-c
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v2 (SAT)"
|
|
||||||
checkout develop
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5️⃣ Bugfix branches
|
|
||||||
|
|
||||||
Bugfix branches are used to quickly patch issues identified before deployment to **LIVE**, typically during **SAT**. They work similarly to feature branches but are intended for urgent fixes rather than planned development.
|
|
||||||
|
|
||||||
- Bugfix branches are always created from the `release` branch.
|
|
||||||
- Once the fix is complete and tested, it must be merged back into `release` via a **pull request**.
|
|
||||||
- The bugfix must also be **back-merged into** `develop` to keep branches consistent.
|
|
||||||
- **Team Leaders** are responsible for reviewing and approving the changes.
|
|
||||||
- Bugfix branches must never interact directly with the `master` branch.
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
---
|
|
||||||
config:
|
|
||||||
theme: 'base'
|
|
||||||
gitGraph:
|
|
||||||
mainBranchName: 'release'
|
|
||||||
showCommitLabel: false
|
|
||||||
---
|
|
||||||
gitGraph
|
|
||||||
commit
|
|
||||||
branch develop
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v1 (SAT)"
|
|
||||||
branch bugfix/fix-bug-a
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge bugfix/fix-bug-a tag: "v2 (SAT)"
|
|
||||||
checkout develop
|
|
||||||
merge bugfix/fix-bug-a
|
|
||||||
checkout release
|
|
||||||
branch bugfix/fix-bug-b
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge bugfix/fix-bug-b tag: "v3 (SAT)"
|
|
||||||
checkout develop
|
|
||||||
merge bugfix/fix-bug-b
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v4 (SAT)"
|
|
||||||
checkout develop
|
|
||||||
commit
|
|
||||||
```
|
|
||||||
|
|
||||||
### 6️⃣ Hotfix branches
|
|
||||||
|
|
||||||
Hotfix branches are used to **quickly patch critical issues in the LIVE environment**.
|
|
||||||
They are similar to bugfix branches but always originate from the master branch, since they address production incidents.
|
|
||||||
|
|
||||||
- Hotfix branches are created from the `master` branch.
|
|
||||||
- Once the fix is complete and tested, it must be merged back into `master` via a **pull request**.
|
|
||||||
- The `master` branch should be tagged with a new LIVE version number.
|
|
||||||
- The hotfix must also be merged into `develop` branch to ensure future development includes the fix.
|
|
||||||
- This ensures all branches remain consistent with the LIVE system.
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
---
|
|
||||||
config:
|
|
||||||
theme: 'base'
|
|
||||||
gitGraph:
|
|
||||||
mainBranchName: 'master'
|
|
||||||
showCommitLabel: false
|
|
||||||
---
|
|
||||||
gitGraph
|
|
||||||
commit
|
|
||||||
branch release
|
|
||||||
branch develop
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v1 (SAT)"
|
|
||||||
checkout master
|
|
||||||
merge release
|
|
||||||
branch hotfix/fix-bug-a
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout master
|
|
||||||
merge hotfix/fix-bug-a tag: "v1.1 (LIVE)"
|
|
||||||
checkout develop
|
|
||||||
merge hotfix/fix-bug-a
|
|
||||||
checkout develop
|
|
||||||
commit
|
|
||||||
commit
|
|
||||||
checkout release
|
|
||||||
merge develop tag: "v2 (SAT)"
|
|
||||||
checkout master
|
|
||||||
merge release
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## **Pull request flow**
|
|
||||||
|
|
||||||
A pull request is a development process that provides a platform for discussion and review of a completed feature. Its purpose is to notify team members that the feature has been completed and it is open for discussion or modifications. The discussion usually occurs to improve the quality of the code; it is basically a code review process.
|
|
||||||
|
|
||||||
### What Needs to Be Done Before Creating a Pull Request?
|
|
||||||
1. Commit code in your feature branch. Note that a feature can have any number of commits.
|
|
||||||
2. Commits made in the branch only reflect changes on the local machine (i.e. your machine). So, the commits need to be pushed to the remote branch.
|
|
||||||
3. Then, you’re ready to rebase your branch. Rebasing is required if any new pull requests were merged after you had taken the feature branch.
|
|
||||||
4. After rebasing, any conflicts that arise need to be resolved, and the code needs to be pushed back to the remote branch.
|
|
||||||
5. Finally, it’s time to create a pull request.
|
|
||||||
|
|
||||||
Note: Pull requests require two distinct branches. There needs to be a difference in the code between the taken branch and source branch.
|
|
||||||
|
|
||||||
### Pull Request Process
|
|
||||||
|
|
||||||
1. When creating a pull request, you add a brief overview of your feature, select the branch to which the code needs to be merged, and select the assignee who will be reviewing it.
|
|
||||||
2. Once it is created, it is open for discussion or modifications.
|
|
||||||
3. Sometimes conflicts occur after creating a pull request, and you must resolve these conflicts.
|
|
||||||
4. Usually, the assigned person reviews the code, but it is not mandatory that only the assignee performs the review. Any team member can take part in the review process and give their feedback or discuss potential modifications to the code.
|
|
||||||
5. Any feedback or modifications are added in the form of comments near the code line.
|
|
||||||
6. The developer resolves comments and replies to the reviewer.
|
|
||||||
7. This process continues until all comments are resolved.
|
|
||||||
8. Once all discussions are resolved, the code is merged to the branch that was selected when the pull request was created.
|
|
||||||
|
|
||||||
Note: Pull requests can be made for any branch. Usually, they are made for the source branch. Sometimes it is okay to close a pull request without merging it. This usually occurs when a feature is dropped.
|
|
||||||
|
|
||||||
### Benefits of Pull Requests
|
|
||||||
- Use this collaborative platform to discuss potential modifications to the code.
|
|
||||||
- Improve code quality.
|
|
||||||
- Simplify the process of receiving feedback from the reviewer.
|
|
||||||
- Address feedback easily in-line near the relevant code.
|
|
||||||
- Provide better stability for the code.
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
|
|
||||||
flowchart TB
|
|
||||||
A(["Source branch"]) --> B[Developer takes a feature branch]
|
|
||||||
B --> C[Makes modifications in code]
|
|
||||||
C --> D[Commits code]
|
|
||||||
D --> E{Is implementation completed?}
|
|
||||||
E -->|No| C
|
|
||||||
E -->|Yes| F[Pushes changes to remote branch]
|
|
||||||
F --> G[Create/Update pull request]
|
|
||||||
G --> H{Conflicts?}
|
|
||||||
H -->|Yes| I[Takes update from source and resolve conflicts]
|
|
||||||
I --> C
|
|
||||||
H -->|No| J{Discussion}
|
|
||||||
J -->|No| C
|
|
||||||
J -->|Yes| K(["Code Merge To Source Branch"])
|
|
||||||
```
|
|
||||||
|
|
||||||
### What Are Merge Conflicts and When Do They Occur in a Pull Request?
|
|
||||||
To better explain what conflicts are, consider a scenario where developer A takes a branch, feature A, from the `develop` branch. Another developer, developer B, takes a branch, feature B, from the `develop` branch.
|
|
||||||
|
|
||||||
Now both developers work on their respective feature branches. Developer A modifies a line or a block of code in the feature A branch. Developer B also modifies the same block of code that developer A has modified but in the feature B branch.
|
|
||||||
|
|
||||||
After completing their features, both developers create pull requests to the `develop` branch; let’s call them pull request A and pull request B. Then, a reviewer merges A. Once A is merged, a conflict arises in B because the same block of code was modified by both developers.
|
|
||||||
|
|
||||||
To resolve the conflict, developer B must rebase the feature B branch by retrieving an update from the `develop` branch (i.e. the source branch). After retrieving the update, developer B faces code conflicts in their local copy of the branch. Now they must resolve the conflicts and again, commit, and push code to the remote `develop` branch. Now the code is free of conflicts, so B can be merged by the reviewer.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
[^1]: Site Acceptance Test
|
|
||||||
@ -1,11 +0,0 @@
|
|||||||
{
|
|
||||||
"label": "Git Workflow",
|
|
||||||
"collapsible": false,
|
|
||||||
"collapsed": false,
|
|
||||||
"className": "blue",
|
|
||||||
"link": {
|
|
||||||
"type": "generated-index",
|
|
||||||
"title": "Git Workflow",
|
|
||||||
"description": "Git Workflow"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
@ -1,94 +0,0 @@
|
|||||||
import type * as Preset from '@docusaurus/preset-classic';
|
|
||||||
import type { Config } from '@docusaurus/types';
|
|
||||||
import { themes as prismThemes } from 'prism-react-renderer';
|
|
||||||
|
|
||||||
// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
|
|
||||||
|
|
||||||
const config: Config = {
|
|
||||||
title: 'Development Workflow',
|
|
||||||
tagline: 'Documentation for Development Workflow',
|
|
||||||
favicon: 'img/favicon.ico',
|
|
||||||
|
|
||||||
// Set the production url of your site here
|
|
||||||
url: 'https://gitea.plp19.com/',
|
|
||||||
// Set the /<baseUrl>/ pathname under which your site is served
|
|
||||||
// For GitHub pages deployment, it is often '/<projectName>/'
|
|
||||||
baseUrl: '/doc-development-workflow/',
|
|
||||||
|
|
||||||
// GitHub pages deployment config.
|
|
||||||
// If you aren't using GitHub pages, you don't need these.
|
|
||||||
organizationName: 'dev-public',
|
|
||||||
projectName: 'doc-development-workflow',
|
|
||||||
|
|
||||||
onBrokenLinks: 'throw',
|
|
||||||
onBrokenMarkdownLinks: 'warn',
|
|
||||||
|
|
||||||
// Even if you don't use internationalization, you can use this field to set
|
|
||||||
// useful metadata like html lang. For example, if your site is Chinese, you
|
|
||||||
// may want to replace "en" with "zh-Hans".
|
|
||||||
i18n: {
|
|
||||||
defaultLocale: 'en',
|
|
||||||
locales: ['en'],
|
|
||||||
},
|
|
||||||
|
|
||||||
presets: [
|
|
||||||
[
|
|
||||||
'classic',
|
|
||||||
{
|
|
||||||
docs: {
|
|
||||||
sidebarPath: './sidebars.ts',
|
|
||||||
routeBasePath: '/',
|
|
||||||
},
|
|
||||||
theme: {
|
|
||||||
customCss: './src/css/custom.css',
|
|
||||||
},
|
|
||||||
} satisfies Preset.Options,
|
|
||||||
],
|
|
||||||
],
|
|
||||||
|
|
||||||
markdown: {
|
|
||||||
mermaid: true,
|
|
||||||
},
|
|
||||||
|
|
||||||
themes: ['@docusaurus/theme-mermaid'],
|
|
||||||
|
|
||||||
themeConfig: {
|
|
||||||
// Replace with your project's social card
|
|
||||||
image: 'img/document-logo.png',
|
|
||||||
navbar: {
|
|
||||||
title: 'Home',
|
|
||||||
logo: {
|
|
||||||
alt: '',
|
|
||||||
src: 'img/document-logo.png',
|
|
||||||
},
|
|
||||||
items: [
|
|
||||||
{
|
|
||||||
type: 'doc',
|
|
||||||
position: 'left',
|
|
||||||
docId: '01-overview',
|
|
||||||
label: 'Docs',
|
|
||||||
},
|
|
||||||
{
|
|
||||||
type: 'html',
|
|
||||||
position: 'right',
|
|
||||||
value: `
|
|
||||||
<a href="https://gitea.plp19.com/dev-public/doc-development-workflow" target="_blank" rel="noopener" style="display: flex; align-items: center; gap: 4px;">
|
|
||||||
<img src="img/gitea-logo.svg" alt="Gitea" style="height: 35px; margin-right: 4px;" />
|
|
||||||
</a>
|
|
||||||
`,
|
|
||||||
},
|
|
||||||
],
|
|
||||||
},
|
|
||||||
footer: {
|
|
||||||
style: 'dark',
|
|
||||||
links: [],
|
|
||||||
copyright: `Copyright © ${new Date().getFullYear()} Game Department, Mercury Studio. Built with Docusaurus.`,
|
|
||||||
},
|
|
||||||
prism: {
|
|
||||||
theme: prismThemes.github,
|
|
||||||
darkTheme: prismThemes.dracula,
|
|
||||||
},
|
|
||||||
} satisfies Preset.ThemeConfig,
|
|
||||||
};
|
|
||||||
|
|
||||||
export default config;
|
|
||||||
122
gitea-management-guide.md
Normal file
122
gitea-management-guide.md
Normal file
@ -0,0 +1,122 @@
|
|||||||
|
# **Gitea Management Guide**
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This guide provides a structured approach to managing Gitea, covering organizations, repositories, permissions, and integrations. It emphasizes security, streamlined collaboration, and automation to enhance software development workflows.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Authentication
|
||||||
|
|
||||||
|
### Signing Up for Gitea
|
||||||
|
|
||||||
|
- Open [https://gitea.plp19.com/](https://gitea.plp19.com/) and click **"Sign in with AzureAD"**.
|
||||||
|
- Follow the on-screen prompts to authenticate using your AzureAD account.
|
||||||
|
- Choose a username and complete the setup process.
|
||||||
|
- After signing in, navigate to **User Settings > Account** and create a new password for enhanced security.
|
||||||
|
|
||||||
|
### Signing In to Gitea
|
||||||
|
|
||||||
|
- Open [https://gitea.plp19.com/](https://gitea.plp19.com/).
|
||||||
|
- Click **"Sign in with AzureAD"** to access your account.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Creating an Organization and Managing Permissions
|
||||||
|
|
||||||
|
Only the Head of Department (HoD) is authorized to create and configure an organization.
|
||||||
|
|
||||||
|
### Creating a New Organization
|
||||||
|
|
||||||
|
- Click the **"+"** icon in the top-right and select **"New Organization"**.
|
||||||
|
- Enter an **Organization Name**.
|
||||||
|
- Set **Visibility** to **Private** (except for special organizations that may be **Public**).
|
||||||
|
- Under **Permissions**, enable **"Repository admin can add and remove team access."**
|
||||||
|
- Click **"Create Organization"**.
|
||||||
|
|
||||||
|
### Configuring Teams
|
||||||
|
|
||||||
|
#### Builders Team
|
||||||
|
|
||||||
|
- Navigate to the **"Teams"** tab and click **"New Team"**.
|
||||||
|
- Enter **Team Name**: **Builders**.
|
||||||
|
- Set **Repository Access**: Allow access to **All repositories**.
|
||||||
|
- Set **Permissions**:
|
||||||
|
- **Code**: Write.
|
||||||
|
- **All Other**: No Access.
|
||||||
|
- Add only the user `jenkins` and save changes.
|
||||||
|
|
||||||
|
#### Leaders Team
|
||||||
|
|
||||||
|
- Navigate to the **"Teams"** tab and click **"New Team"**.
|
||||||
|
- Enter **Team Name**: **Leaders**.
|
||||||
|
- Set **Repository Access**: Allow access to **All Repositories** and enable **Create Repositories**.
|
||||||
|
- Set **Permission**: **Administrator Access**.
|
||||||
|
- Add only the **Team Leaders** and save changes.
|
||||||
|
|
||||||
|
#### Developers Team
|
||||||
|
|
||||||
|
- Navigate to the **"Teams"** tab and click **"New Team"**.
|
||||||
|
- Enter **Team Name**: **Developers**.
|
||||||
|
- Set **Repository Access**: Allow access to **All Repositories**.
|
||||||
|
- Set **Permissions**:
|
||||||
|
- **Code**: Write access (modify source code, commit changes, push branches).
|
||||||
|
- **Issues**: Write access (create, comment, manage issues).
|
||||||
|
- **Pull Request**: Write access (create, review, merge pull requests).
|
||||||
|
- **Wiki**: Write access (create, edit, manage wiki pages).
|
||||||
|
- **Project**: Write access (create, edit, manage project boards).
|
||||||
|
- **Releases**: Read access (view releases).
|
||||||
|
- **Packages**: Read access (view and download packages).
|
||||||
|
- Add relevant users and save changes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Creating and Managing Repositories
|
||||||
|
|
||||||
|
Only the Head of Department and Team Leaders are authorized to create and configure repositories.
|
||||||
|
|
||||||
|
### Creating a New Repository
|
||||||
|
|
||||||
|
- Click the **"+"** icon in the top-right and select **"New Repository"**.
|
||||||
|
- Enter an **Organization Name**.
|
||||||
|
- Enter Repository Details:
|
||||||
|
- **Owner**: Choose the organization as the owner (personal accounts are not allowed).
|
||||||
|
- **Repository Name**: Choose a descriptive name.
|
||||||
|
- **Description**: (Optional) Add a brief description.
|
||||||
|
- **Visibility**: Set to **Private** (except for special projects that may be **Public**).
|
||||||
|
- **Default Branch**: Set to **develop** for consistency.
|
||||||
|
- Click **Create Repository** to finalize.
|
||||||
|
|
||||||
|
### Configuring Repository Settings
|
||||||
|
|
||||||
|
- Navigate to the repository and click on the **Settings** tab.
|
||||||
|
- **Disable Non-Essential Features**:
|
||||||
|
- Wiki
|
||||||
|
- Issues
|
||||||
|
- Projects
|
||||||
|
- Releases
|
||||||
|
- Packages
|
||||||
|
- **Pull Request Configuration**:
|
||||||
|
- Enable **Delete pull request branch after merging by default**.
|
||||||
|
- Enable **Ignore Whitespace for Conflicts**.
|
||||||
|
|
||||||
|
### Adding Branch Protection for `develop` and `master`
|
||||||
|
|
||||||
|
- Navigate to the **Branches** tab and select **Add New Rule**.
|
||||||
|
- Set **Protected Branch Name Pattern**: `develop` / `master`.
|
||||||
|
- Enable **Restrict approvals to whitelisted users or teams**.
|
||||||
|
- Select **Whitelisted teams for reviews**: `Leaders`.
|
||||||
|
- Enable **Merge Whitelist**.
|
||||||
|
- Select **Whitelisted teams for merging**: `Leaders`.
|
||||||
|
- Enable the following options:
|
||||||
|
- **Block merge on rejected reviews**
|
||||||
|
- **Block merge on official review requests**
|
||||||
|
- **Block merge if pull request is outdated**
|
||||||
|
- Click **Save Rule**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
By following these structured guidelines, teams can effectively manage Gitea repositories while maintaining security, collaboration, and workflow efficiency. Proper team assignments and repository configurations help streamline development processes, enforce best practices, and ensure controlled access to critical resources.
|
||||||
|
|
||||||
141
gitflow-workflow.md
Normal file
141
gitflow-workflow.md
Normal file
@ -0,0 +1,141 @@
|
|||||||
|
# **GitFlow Workflow**
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
GitFlow is a branching model for Git that helps teams manage feature development and release cycles efficiently. It standardizes how branches are structured, making collaboration easier and ensuring a smooth release process.
|
||||||
|
|
||||||
|
## Git Repository
|
||||||
|
|
||||||
|
🔗 [https://gitea.plp19.com/](https://gitea.plp19.com/)
|
||||||
|
|
||||||
|
## Organization Permissions:
|
||||||
|
|
||||||
|
✅ Only the Head of Department (HoD) can create, modify, and delete organizations.\
|
||||||
|
✅ Only the HoD can add teams and grant permissions for organizations. 
|
||||||
|
|
||||||
|
## Repository Permissions:
|
||||||
|
|
||||||
|
✅ Only the HoD and Team Leaders can create, modify, and delete repository.\
|
||||||
|
✅ Only the HoD and Team Leaders can change settings for repository.
|
||||||
|
|
||||||
|
## Branch Permissions
|
||||||
|
|
||||||
|
### ✅ `master` branch: production branch
|
||||||
|
|
||||||
|
- Prevent rewriting history.
|
||||||
|
- Prevent branch deletion.
|
||||||
|
- Prevent changes without a pull request.
|
||||||
|
- Limit write access to Team Leaders.
|
||||||
|
|
||||||
|
### ✅ `develop` branch: development branch
|
||||||
|
|
||||||
|
- Prevent rewriting history.
|
||||||
|
- Prevent branch deletion.
|
||||||
|
- Prevent changes without a pull request.
|
||||||
|
- Limit write access to Team Leaders.
|
||||||
|
|
||||||
|
### ✅ Other branches
|
||||||
|
|
||||||
|
- Full access for all users in the repository.
|
||||||
|
|
||||||
|
## Branch Prefixes
|
||||||
|
|
||||||
|
### ✅Bugfix: `bugfix/`
|
||||||
|
|
||||||
|
Typically used to fix bugs in a development branch.
|
||||||
|
|
||||||
|
### ✅Feature: `feature/`
|
||||||
|
|
||||||
|
Used for specific feature development, typically branching from and merging back into the development branch.
|
||||||
|
|
||||||
|
### ✅Hotfix: `hotfix/`
|
||||||
|
|
||||||
|
Typically used to quickly fix the production branch.
|
||||||
|
|
||||||
|
|
||||||
|
# Gitflow
|
||||||
|
|
||||||
|
Gitflow is really just an abstract idea of a Git workflow. This means it dictates what kind of branches to set up and how to merge them together. We will touch on the purposes of the branches below.
|
||||||
|
|
||||||
|
## 1️⃣ Master Branch
|
||||||
|
|
||||||
|
The `master` branch contains the latest updates for the project currently running in the LIVE environment.
|
||||||
|
|
||||||
|
Any changes to the `master` branch must be performed through a pull request. Team Leaders will review and merge the changes accordingly.
|
||||||
|
|
||||||
|
|
||||||
|
## 2️⃣ Develop Branch
|
||||||
|
|
||||||
|
Develop branch contains the complete history of the project and serves as an integration branch for features.
|
||||||
|
|
||||||
|
We will create the SAT (Site Acceptance Test) version on the `develop` branch and tag it with an updated version number. Once approved and deployed to LIVE, we will merge this confirmed version into the `master` branch.
|
||||||
|
|
||||||
|
Any changes for the `develop` branch must be performed through pull request. Team Leaders will review and merge the changes accordingly.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 3️⃣ Feature branches
|
||||||
|
|
||||||
|
Each new feature should be developed in its own branch and pushed to the central repository for backup and collaboration. However, instead of branching from the `master` branch, feature branches should originate from the `develop` branch. Once a feature is complete, it should be merged back into the `develop` branch. Features must never interact directly with the `master` branch.
|
||||||
|
|
||||||
|
Feature branches are generally created from the latest `develop` branch.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 4️⃣ Bugfix branches
|
||||||
|
|
||||||
|
Bugfix branches are used to quickly patch for SAT versions. Bugfix branches are a lot like feature branches that will use `develop` as their parent branch. Once the fix is complete, it should be merged into the `develop` branch.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 5️⃣ Hotfix branches
|
||||||
|
|
||||||
|
Hotfix branches are used to quickly patch production releases. Hotfix branches are a lot like bugfix branches and feature branches except they're based on `master` instead of `develop`. This is the only branch that should fork directly off of `master`. Once a feature is complete, it should be merged into both `master` and `develop`, and `master` should be tagged with an updated version number.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# Pull request flow
|
||||||
|
A pull request is a development process that provides a platform for discussion and review of a completed feature. Its purpose is to notify team members that the feature has been completed and it is open for discussion or modifications. The discussion usually occurs to improve the quality of the code; it is basically a code review process.
|
||||||
|
|
||||||
|
## What Needs to Be Done Before Creating a Pull Request?
|
||||||
|
1. Commit code in your feature branch. Note that a feature can have any number of commits.
|
||||||
|
2. Commits made in the branch only reflect changes on the local machine (i.e. your machine). So, the commits need to be pushed to the remote branch.
|
||||||
|
3. Then, you’re ready to rebase your branch. Rebasing is required if any new pull requests were merged after you had taken the feature branch.
|
||||||
|
4. After rebasing, any conflicts that arise need to be resolved, and the code needs to be pushed back to the remote branch.
|
||||||
|
5. Finally, it’s time to create a pull request.
|
||||||
|
|
||||||
|
Note: Pull requests require two distinct branches. There needs to be a difference in the code between the taken branch and source branch.
|
||||||
|
|
||||||
|
## Pull Request Process
|
||||||
|
|
||||||
|
1. When creating a pull request, you add a brief overview of your feature, select the branch to which the code needs to be merged, and select the assignee who will be reviewing it.
|
||||||
|
2. Once it is created, it is open for discussion or modifications.
|
||||||
|
3. Sometimes conflicts occur after creating a pull request, and you must resolve these conflicts.
|
||||||
|
4. Usually, the assigned person reviews the code, but it is not mandatory that only the assignee performs the review. Any team member can take part in the review process and give their feedback or discuss potential modifications to the code.
|
||||||
|
5. Any feedback or modifications are added in the form of comments near the code line.
|
||||||
|
6. The developer resolves comments and replies to the reviewer.
|
||||||
|
7. This process continues until all comments are resolved.
|
||||||
|
8. Once all discussions are resolved, the code is merged to the branch that was selected when the pull request was created.
|
||||||
|
|
||||||
|
Note: Pull requests can be made for any branch. Usually, they are made for the source branch. Sometimes it is okay to close a pull request without merging it. This usually occurs when a feature is dropped.
|
||||||
|
|
||||||
|
## Benefits of Pull Requests
|
||||||
|
- Use this collaborative platform to discuss potential modifications to the code.
|
||||||
|
- Improve code quality.
|
||||||
|
- Simplify the process of receiving feedback from the reviewer.
|
||||||
|
- Address feedback easily in-line near the relevant code.
|
||||||
|
- Provide better stability for the code.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## What Are Merge Conflicts and When Do They Occur in a Pull Request?
|
||||||
|
To better explain what conflicts are, consider a scenario where developer A takes a branch, feature A, from the develop branch. Another developer, developer B, takes a branch, feature B, from the develop branch.
|
||||||
|
|
||||||
|
Now both developers work on their respective feature branches. Developer A modifies a line or a block of code in the feature A branch. Developer B also modifies the same block of code that developer A has modified but in the feature B branch.
|
||||||
|
|
||||||
|
After completing their features, both developers create pull requests to the develop branch; let’s call them pull request A and pull request B. Then, a reviewer merges A. Once A is merged, a conflict arises in B because the same block of code was modified by both developers.
|
||||||
|
|
||||||
|
To resolve the conflict, developer B must rebase the feature B branch by retrieving an update from the develop branch (i.e. the source branch). After retrieving the update, developer B faces code conflicts in their local copy of the branch. Now they must resolve the conflicts and again, commit, and push code to the remote develop branch. Now the code is free of conflicts, so B can be merged by the reviewer.
|
||||||
|
|
||||||
|
# **Thanks for reading!**
|
||||||
BIN
images/gitflow-workflow/bugfix-branch-diagram.png
Normal file
BIN
images/gitflow-workflow/bugfix-branch-diagram.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
BIN
images/gitflow-workflow/develop-branch-diagram.png
Normal file
BIN
images/gitflow-workflow/develop-branch-diagram.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
BIN
images/gitflow-workflow/feature-branch-diagram.png
Normal file
BIN
images/gitflow-workflow/feature-branch-diagram.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
BIN
images/gitflow-workflow/git-icon.png
Normal file
BIN
images/gitflow-workflow/git-icon.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 6.4 KiB |
BIN
images/gitflow-workflow/hotfix-branch-diagram.png
Normal file
BIN
images/gitflow-workflow/hotfix-branch-diagram.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
images/gitflow-workflow/master-branch-diagram.png
Normal file
BIN
images/gitflow-workflow/master-branch-diagram.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
BIN
images/gitflow-workflow/pull-request-workflow.png
Normal file
BIN
images/gitflow-workflow/pull-request-workflow.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
BIN
images/jenkins-management-guide/authorization-chart.jpg
Normal file
BIN
images/jenkins-management-guide/authorization-chart.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 156 KiB |
169
jenkins-management-guide.md
Normal file
169
jenkins-management-guide.md
Normal file
@ -0,0 +1,169 @@
|
|||||||
|
# **Jenkins Management Guide**
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
Jenkins is a widely used open-source automation server that facilitates continuous integration and continuous deployment (CI/CD). This guide is designed to help team leaders understand how to use Jenkins to build and deploy game projects efficiently. It covers how to create, set up, and manage new build jobs, ensuring stability, security, and streamlined development workflows.
|
||||||
|
|
||||||
|
## Authentication
|
||||||
|
|
||||||
|
Ensuring secure access to Jenkins is crucial for maintaining project integrity and preventing unauthorized changes. Only the HoD has permission to configure authentication settings, ensuring centralized control over user access.
|
||||||
|
|
||||||
|
### Authentication Methods
|
||||||
|
|
||||||
|
**Built-in Jenkins User Database**: The default authentication method where users are managed directly in Jenkins. User accounts are provided and managed by HoD.
|
||||||
|
|
||||||
|
### Steps to Create a New User in Jenkins
|
||||||
|
|
||||||
|
1. **Log in to Jenkins** as HoD.
|
||||||
|
2. Navigate to **Manage Jenkins** > **Users**.
|
||||||
|
3. Click on **Create User**.
|
||||||
|
4. Fill in the required details:
|
||||||
|
- **Username**: A unique identifier for the user.
|
||||||
|
- **Password**: A secure password for authentication.
|
||||||
|
- **Full Name**: The user’s full name.
|
||||||
|
- **Email Address**: Used for notifications and communication.
|
||||||
|
5. Click **Create User** to finalize the process.
|
||||||
|
|
||||||
|
### Authorization
|
||||||
|
- **HoD**[^1]: Full administrative access with capabilities to manage security settings and user accounts. Can create, modify, and oversee build jobs.
|
||||||
|
- **Team Leaders**: Can only trigger build jobs and view results and logs.
|
||||||
|
- **Anonymous**: Can only view build results and logs.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### Steps to Change Authorization
|
||||||
|
|
||||||
|
1. **Log in to Jenkins** as the HoD.
|
||||||
|
2. Navigate to **Manage Jenkins** > **Security**.
|
||||||
|
3. Locate the **Authorization** section.
|
||||||
|
4. Select **Matrix-based security** if not already enabled.
|
||||||
|
5. Modify user or group permissions by checking or unchecking relevant boxes:
|
||||||
|
- Grant or restrict access to specific Jenkins features.
|
||||||
|
- Ensure only authorized users have administrative privileges.
|
||||||
|
6. Click **Save** to apply the changes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Jenkins Agents
|
||||||
|
|
||||||
|
Jenkins agents are used to distribute build and deployment workloads across multiple machines, improving performance and scalability. Agents allow Jenkins to execute tasks on different platforms or dedicated environments.
|
||||||
|
|
||||||
|
### Steps to Set Up a Jenkins Agent
|
||||||
|
|
||||||
|
1. **Log in to Jenkins** as the HoD.
|
||||||
|
2. Navigate to **Manage Jenkins** > **Nodes**.
|
||||||
|
3. Click **New Node** and provide a name for the agent.
|
||||||
|
4. Select **Permanent Agent** and click **OK**.
|
||||||
|
5. Configure environment variables or tools if required.
|
||||||
|
6. Click Save to finalize.
|
||||||
|
|
||||||
|
### Steps to Start the Jenkins Agent
|
||||||
|
|
||||||
|
1. Navigate to **Manage Jenkins** > **Nodes**.
|
||||||
|
2. Select the offline agent from the list.
|
||||||
|
3. Go to the **Status** tab of the selected agent 
|
||||||
|
4. Follow the guide provided there to start the agent.
|
||||||
|
5. Verify that the agent status changes to Online in the Dashboard.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Creating and Managing Jobs
|
||||||
|
|
||||||
|
Jenkins jobs define the tasks for building, testing, and deploying projects.
|
||||||
|
|
||||||
|
### Steps to Create a New Job
|
||||||
|
|
||||||
|
1. **Log in to Jenkins** as the HoD.
|
||||||
|
2. Click **New Item** from the Jenkins dashboard.
|
||||||
|
3. Enter a **Job Name** that reflects the purpose of the build.
|
||||||
|
4. Select the appropriate job type.
|
||||||
|
5. Click **OK** to create the job.
|
||||||
|
6. Configure the job settings:
|
||||||
|
- **Add Build Parameters**: Configure dynamic input parameters for builds.
|
||||||
|
- **Define a Custom Workspace**: Specify a custom directory for build execution.
|
||||||
|
- **Allow Remote Build Triggering**: Enable builds to be triggered via remote requests.
|
||||||
|
- **Add Build Step with Windows Batch Command**:
|
||||||
|
- Click **Add Build Step**.
|
||||||
|
- Select **Execute Windows Batch Command**.
|
||||||
|
- Enter the batch script commands required for the build process.
|
||||||
|
- Click **Save**.
|
||||||
|
7. Click **Save** to finalize the job configuration.
|
||||||
|
|
||||||
|
### Steps to Trigger a Build Job
|
||||||
|
|
||||||
|
#### Using the Jenkins UI
|
||||||
|
|
||||||
|
1. **Log in to Jenkins**.
|
||||||
|
2. Navigate to the **Jenkins Dashboard**.
|
||||||
|
3. Select the desired job from the list and click on it to open the job details page.
|
||||||
|
4. If the job has parameters, fill in the required values in the parameter fields before proceeding.
|
||||||
|
4. Click on **Build Now**.
|
||||||
|
5. Monitor the build progress in the **Build History** section.
|
||||||
|
6. Click on a specific build to view detailed logs and console output.
|
||||||
|
|
||||||
|
#### Triggering a Build Remotely
|
||||||
|
|
||||||
|
1. Use a web request (such as `curl` or Postman) to trigger the build:
|
||||||
|
```sh
|
||||||
|
curl --user JENKINS_USERNAME:JENKINS_PASSWORD --location --request GET "http://your-jenkins-server/job/YOUR_JOB_NAME/buildWithParameters?token=YOUR_SECRET_TOKEN&PARAM_NAME=PARAM_VALUE"
|
||||||
|
```
|
||||||
|
2. Check the **Build History** section to verify that the job has started.
|
||||||
|
3. Monitor the build progress and logs as needed.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Setting Up Notifications for Microsoft Teams
|
||||||
|
|
||||||
|
Integrating Jenkins with Microsoft Teams allows build notifications to be sent directly to a Teams channel, keeping the team informed of build statuses.
|
||||||
|
|
||||||
|
### Steps to Configure Microsoft Teams Notifications
|
||||||
|
|
||||||
|
1. **Create an Incoming Webhook in Microsoft Teams**:
|
||||||
|
- Open Microsoft Teams and navigate to the desired channel.
|
||||||
|
- Click on **More Options (⋮)** > **Connectors**.
|
||||||
|
- Search for **Incoming Webhook** and click **Add**.
|
||||||
|
- Provide a name for the webhook and upload an optional image.
|
||||||
|
- Click **Create** and copy the generated webhook URL.
|
||||||
|
####
|
||||||
|
2. **Configure Job to Send Notifications**:
|
||||||
|
- Open the desired job in Jenkins.
|
||||||
|
- Click **Configure**.
|
||||||
|
- Scroll down to the **Office 365 Connector / Power Automate workflows** section.
|
||||||
|
- Paste the Microsoft Teams webhook URL copied earlier.
|
||||||
|
- Configure the message format and triggers (e.g., on build success, failure, etc.).
|
||||||
|
- Click **Save**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Builder Script
|
||||||
|
The Builder Script is a step-by-step script that automates the entire process of building a project. It is designed to guide Jenkins through each phase of the build process, ensuring that each task, such as retrieving dependencies, compiling code, and packaging the final product, is done in the correct order. This script is useful for maintaining a consistent build process, improving automation, and minimizing human error during development.
|
||||||
|
|
||||||
|
By integrating this script into your Jenkins job, you can ensure that every project build follows the same structured procedure, making it easier to manage and debug builds when necessary.
|
||||||
|
|
||||||
|
### Repository Url
|
||||||
|
https://gitea.plp19.com/dev-tools/p4f-project-builder.git
|
||||||
|
|
||||||
|
### Add Initial Build Step to Clone and Update the Builder Script
|
||||||
|
You need to add the following code as the first build step in every Jenkins build job to ensure that the latest version of the builder script is used and that all dependencies are correctly set up before proceeding with the build process.
|
||||||
|
|
||||||
|
```sh
|
||||||
|
echo off
|
||||||
|
set BUILDER_PATH="C:\Tools\p4f-project-builder"
|
||||||
|
|
||||||
|
if not exist %BUILDER_PATH% (
|
||||||
|
git clone https://jenkins:jenkins@gitea.plp19.com/dev-tools/p4f-project-builder.git %BUILDER_PATH%
|
||||||
|
)
|
||||||
|
|
||||||
|
cd %BUILDER_PATH%
|
||||||
|
git add --a
|
||||||
|
git reset --hard
|
||||||
|
git checkout develop
|
||||||
|
git fetch
|
||||||
|
git pull
|
||||||
|
call npm install
|
||||||
|
cd %WORKSPACE%
|
||||||
|
|
||||||
|
exit /b 0
|
||||||
|
```
|
||||||
|
|
||||||
|
[^1]: Head of Department
|
||||||
19464
package-lock.json
generated
19464
package-lock.json
generated
File diff suppressed because it is too large
Load Diff
49
package.json
49
package.json
@ -1,49 +0,0 @@
|
|||||||
{
|
|
||||||
"name": "doc-cocos-creator-3-research",
|
|
||||||
"version": "0.0.0",
|
|
||||||
"private": true,
|
|
||||||
"scripts": {
|
|
||||||
"docusaurus": "docusaurus",
|
|
||||||
"start": "docusaurus start",
|
|
||||||
"build": "docusaurus build",
|
|
||||||
"swizzle": "docusaurus swizzle",
|
|
||||||
"deploy": "docusaurus deploy",
|
|
||||||
"clear": "docusaurus clear",
|
|
||||||
"serve": "docusaurus serve",
|
|
||||||
"write-translations": "docusaurus write-translations",
|
|
||||||
"write-heading-ids": "docusaurus write-heading-ids",
|
|
||||||
"typecheck": "tsc"
|
|
||||||
},
|
|
||||||
"dependencies": {
|
|
||||||
"@docusaurus/core": "^3.8.1",
|
|
||||||
"@docusaurus/preset-classic": "^3.8.1",
|
|
||||||
"@docusaurus/theme-mermaid": "^3.8.1",
|
|
||||||
"@docusaurus/theme-search-algolia": "^3.8.1",
|
|
||||||
"@mdx-js/react": "3.0.0",
|
|
||||||
"clsx": "2.0.0",
|
|
||||||
"prism-react-renderer": "2.3.0",
|
|
||||||
"react": "19.0.0",
|
|
||||||
"react-dom": "19.0.0"
|
|
||||||
},
|
|
||||||
"devDependencies": {
|
|
||||||
"@docusaurus/module-type-aliases": "^3.8.1",
|
|
||||||
"@docusaurus/tsconfig": "^3.8.1",
|
|
||||||
"@docusaurus/types": "3.8.0",
|
|
||||||
"typescript": "5.6.2"
|
|
||||||
},
|
|
||||||
"browserslist": {
|
|
||||||
"production": [
|
|
||||||
">0.5%",
|
|
||||||
"not dead",
|
|
||||||
"not op_mini all"
|
|
||||||
],
|
|
||||||
"development": [
|
|
||||||
"last 3 chrome version",
|
|
||||||
"last 3 firefox version",
|
|
||||||
"last 5 safari version"
|
|
||||||
]
|
|
||||||
},
|
|
||||||
"engines": {
|
|
||||||
"node": ">=18.0"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
30
readme.md
30
readme.md
@ -1,30 +0,0 @@
|
|||||||
# Research Notes Documentation
|
|
||||||
|
|
||||||
This project serves as a centralized knowledge base for organizing research notes, technical findings, and supporting documentation related to internal development tools and workflows.
|
|
||||||
|
|
||||||
Built using [Docusaurus](https://docusaurus.io/), it provides a clean, navigable structure for maintaining and accessing information over time.
|
|
||||||
|
|
||||||
## Getting Started
|
|
||||||
|
|
||||||
1. Clone the repository:
|
|
||||||
```bash
|
|
||||||
git clone https://gitea.plp19.com/dev-public/doc-research-notes.git
|
|
||||||
cd doc-research-notes
|
|
||||||
```
|
|
||||||
2. Install dependencies:
|
|
||||||
```bash
|
|
||||||
npm install
|
|
||||||
```
|
|
||||||
3. Start the development server:
|
|
||||||
```bash
|
|
||||||
npm start
|
|
||||||
```
|
|
||||||
4. Open the browser and navigate to `http://localhost:3000` to view the documentation.
|
|
||||||
|
|
||||||
## Contributing
|
|
||||||
|
|
||||||
Contributions are welcome! Please feel free to submit a Pull Request.
|
|
||||||
|
|
||||||
## License
|
|
||||||
|
|
||||||
This project is internal and proprietary. Do not distribute outside the organization.
|
|
||||||
33
sidebars.ts
33
sidebars.ts
@ -1,33 +0,0 @@
|
|||||||
import type { SidebarsConfig } from '@docusaurus/plugin-content-docs';
|
|
||||||
|
|
||||||
// This runs in Node.js - Don't use client-side code here (browser APIs, JSX...)
|
|
||||||
|
|
||||||
/**
|
|
||||||
* Creating a sidebar enables you to:
|
|
||||||
- create an ordered group of docs
|
|
||||||
- render a sidebar for each doc of that group
|
|
||||||
- provide next/previous navigation
|
|
||||||
|
|
||||||
The sidebars can be generated from the filesystem, or explicitly defined here.
|
|
||||||
|
|
||||||
Create as many sidebars as you want.
|
|
||||||
*/
|
|
||||||
const sidebars: SidebarsConfig = {
|
|
||||||
// By default, Docusaurus generates a sidebar from the docs folder structure
|
|
||||||
tutorialSidebar: [{ type: 'autogenerated', dirName: '.' }],
|
|
||||||
|
|
||||||
// But you can create a sidebar manually
|
|
||||||
/*
|
|
||||||
tutorialSidebar: [
|
|
||||||
'intro',
|
|
||||||
'hello',
|
|
||||||
{
|
|
||||||
type: 'category',
|
|
||||||
label: 'Tutorial',
|
|
||||||
items: ['tutorial-basics/create-a-document'],
|
|
||||||
},
|
|
||||||
],
|
|
||||||
*/
|
|
||||||
};
|
|
||||||
|
|
||||||
export default sidebars;
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
/**
|
|
||||||
* Any CSS included here will be global. The classic template
|
|
||||||
* bundles Infima by default. Infima is a CSS framework designed to
|
|
||||||
* work well for content-centric websites.
|
|
||||||
*/
|
|
||||||
|
|
||||||
/* You can override the default Infima variables here. */
|
|
||||||
:root {
|
|
||||||
--ifm-color-primary: #2e8555;
|
|
||||||
--ifm-color-primary-dark: #29784c;
|
|
||||||
--ifm-color-primary-darker: #277148;
|
|
||||||
--ifm-color-primary-darkest: #205d3b;
|
|
||||||
--ifm-color-primary-light: #33925d;
|
|
||||||
--ifm-color-primary-lighter: #359962;
|
|
||||||
--ifm-color-primary-lightest: #3cad6e;
|
|
||||||
--ifm-code-font-size: 95%;
|
|
||||||
--docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
|
|
||||||
}
|
|
||||||
|
|
||||||
/* For readability concerns, you should choose a lighter palette in dark mode. */
|
|
||||||
[data-theme='dark'] {
|
|
||||||
--ifm-color-primary: #25c2a0;
|
|
||||||
--ifm-color-primary-dark: #21af90;
|
|
||||||
--ifm-color-primary-darker: #1fa588;
|
|
||||||
--ifm-color-primary-darkest: #1a8870;
|
|
||||||
--ifm-color-primary-light: #29d5b0;
|
|
||||||
--ifm-color-primary-lighter: #32d8b4;
|
|
||||||
--ifm-color-primary-lightest: #4fddbf;
|
|
||||||
--docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3);
|
|
||||||
}
|
|
||||||
@ -1,23 +0,0 @@
|
|||||||
/**
|
|
||||||
* CSS files with the .module.css suffix will be treated as CSS modules
|
|
||||||
* and scoped locally.
|
|
||||||
*/
|
|
||||||
|
|
||||||
.heroBanner {
|
|
||||||
padding: 4rem 0;
|
|
||||||
text-align: center;
|
|
||||||
position: relative;
|
|
||||||
overflow: hidden;
|
|
||||||
}
|
|
||||||
|
|
||||||
@media screen and (max-width: 996px) {
|
|
||||||
.heroBanner {
|
|
||||||
padding: 2rem;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
.buttons {
|
|
||||||
display: flex;
|
|
||||||
align-items: center;
|
|
||||||
justify-content: center;
|
|
||||||
}
|
|
||||||
@ -1,44 +0,0 @@
|
|||||||
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
|
|
||||||
import Heading from '@theme/Heading';
|
|
||||||
import Layout from '@theme/Layout';
|
|
||||||
import clsx from 'clsx';
|
|
||||||
import type { ReactNode } from 'react';
|
|
||||||
|
|
||||||
import Link from '@docusaurus/Link';
|
|
||||||
import styles from './index.module.css';
|
|
||||||
|
|
||||||
function HomepageHeader()
|
|
||||||
{
|
|
||||||
const { siteConfig } = useDocusaurusContext();
|
|
||||||
return (
|
|
||||||
<header className={clsx('hero hero--primary', styles.heroBanner)}>
|
|
||||||
<div className="container">
|
|
||||||
<Heading as="h1" className="hero__title">
|
|
||||||
{siteConfig.title}
|
|
||||||
</Heading>
|
|
||||||
<p className="hero__subtitle">{siteConfig.tagline}</p>
|
|
||||||
<div className={styles.buttons}>
|
|
||||||
<Link
|
|
||||||
className="button button--secondary button--lg"
|
|
||||||
to="/01-overview">
|
|
||||||
Get Started
|
|
||||||
</Link>
|
|
||||||
</div>
|
|
||||||
</div>
|
|
||||||
</header>
|
|
||||||
);
|
|
||||||
}
|
|
||||||
|
|
||||||
export default function Home(): ReactNode
|
|
||||||
{
|
|
||||||
const { siteConfig } = useDocusaurusContext();
|
|
||||||
return (
|
|
||||||
<Layout
|
|
||||||
title={`${siteConfig.title}`}
|
|
||||||
description="">
|
|
||||||
<HomepageHeader />
|
|
||||||
<main>
|
|
||||||
</main>
|
|
||||||
</Layout>
|
|
||||||
);
|
|
||||||
}
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
title: Markdown page example
|
|
||||||
---
|
|
||||||
|
|
||||||
# Markdown page example
|
|
||||||
|
|
||||||
You don't need React to write simple standalone pages.
|
|
||||||
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 4.2 KiB |
@ -1 +0,0 @@
|
|||||||
<svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" viewBox="0 0 640 640" width="32" height="32"><path d="m395.9 484.2-126.9-61c-12.5-6-17.9-21.2-11.8-33.8l61-126.9c6-12.5 21.2-17.9 33.8-11.8 17.2 8.3 27.1 13 27.1 13l-.1-109.2 16.7-.1.1 117.1s57.4 24.2 83.1 40.1c3.7 2.3 10.2 6.8 12.9 14.4 2.1 6.1 2 13.1-1 19.3l-61 126.9c-6.2 12.7-21.4 18.1-33.9 12" style="fill:#fff"/><path d="M622.7 149.8c-4.1-4.1-9.6-4-9.6-4s-117.2 6.6-177.9 8c-13.3.3-26.5.6-39.6.7v117.2c-5.5-2.6-11.1-5.3-16.6-7.9 0-36.4-.1-109.2-.1-109.2-29 .4-89.2-2.2-89.2-2.2s-141.4-7.1-156.8-8.5c-9.8-.6-22.5-2.1-39 1.5-8.7 1.8-33.5 7.4-53.8 26.9C-4.9 212.4 6.6 276.2 8 285.8c1.7 11.7 6.9 44.2 31.7 72.5 45.8 56.1 144.4 54.8 144.4 54.8s12.1 28.9 30.6 55.5c25 33.1 50.7 58.9 75.7 62 63 0 188.9-.1 188.9-.1s12 .1 28.3-10.3c14-8.5 26.5-23.4 26.5-23.4S547 483 565 451.5c5.5-9.7 10.1-19.1 14.1-28 0 0 55.2-117.1 55.2-231.1-1.1-34.5-9.6-40.6-11.6-42.6M125.6 353.9c-25.9-8.5-36.9-18.7-36.9-18.7S69.6 321.8 60 295.4c-16.5-44.2-1.4-71.2-1.4-71.2s8.4-22.5 38.5-30c13.8-3.7 31-3.1 31-3.1s7.1 59.4 15.7 94.2c7.2 29.2 24.8 77.7 24.8 77.7s-26.1-3.1-43-9.1m300.3 107.6s-6.1 14.5-19.6 15.4c-5.8.4-10.3-1.2-10.3-1.2s-.3-.1-5.3-2.1l-112.9-55s-10.9-5.7-12.8-15.6c-2.2-8.1 2.7-18.1 2.7-18.1L322 273s4.8-9.7 12.2-13c.6-.3 2.3-1 4.5-1.5 8.1-2.1 18 2.8 18 2.8L467.4 315s12.6 5.7 15.3 16.2c1.9 7.4-.5 14-1.8 17.2-6.3 15.4-55 113.1-55 113.1" style="fill:#609926"/><path d="M326.8 380.1c-8.2.1-15.4 5.8-17.3 13.8s2 16.3 9.1 20c7.7 4 17.5 1.8 22.7-5.4 5.1-7.1 4.3-16.9-1.8-23.1l24-49.1c1.5.1 3.7.2 6.2-.5 4.1-.9 7.1-3.6 7.1-3.6 4.2 1.8 8.6 3.8 13.2 6.1 4.8 2.4 9.3 4.9 13.4 7.3.9.5 1.8 1.1 2.8 1.9 1.6 1.3 3.4 3.1 4.7 5.5 1.9 5.5-1.9 14.9-1.9 14.9-2.3 7.6-18.4 40.6-18.4 40.6-8.1-.2-15.3 5-17.7 12.5-2.6 8.1 1.1 17.3 8.9 21.3s17.4 1.7 22.5-5.3c5-6.8 4.6-16.3-1.1-22.6 1.9-3.7 3.7-7.4 5.6-11.3 5-10.4 13.5-30.4 13.5-30.4.9-1.7 5.7-10.3 2.7-21.3-2.5-11.4-12.6-16.7-12.6-16.7-12.2-7.9-29.2-15.2-29.2-15.2s0-4.1-1.1-7.1c-1.1-3.1-2.8-5.1-3.9-6.3 4.7-9.7 9.4-19.3 14.1-29-4.1-2-8.1-4-12.2-6.1-4.8 9.8-9.7 19.7-14.5 29.5-6.7-.1-12.9 3.5-16.1 9.4-3.4 6.3-2.7 14.1 1.9 19.8z" style="fill:#609926"/></svg>
|
|
||||||
|
Before Width: | Height: | Size: 2.1 KiB |
@ -1,11 +0,0 @@
|
|||||||
{
|
|
||||||
// This file is not used in compilation. It is here just for a nice editor experience.
|
|
||||||
"extends": "@docusaurus/tsconfig",
|
|
||||||
"compilerOptions": {
|
|
||||||
"baseUrl": "."
|
|
||||||
},
|
|
||||||
"exclude": [
|
|
||||||
".docusaurus",
|
|
||||||
"build"
|
|
||||||
]
|
|
||||||
}
|
|
||||||
Loading…
x
Reference in New Issue
Block a user