An internal Git server uses the same CI sequence: fetch a change, run its tests and retain the successful commit’s artifact. With Gitea and Jenkins, also manage the network path and repository credentials explicitly. Keep those permissions separate from the machine that executes the build.
It assumes an environment where the Jenkins controller and Linux agent are prepared. Installation can be done by connecting to Ubuntu Jenkins installation or Rocky Jenkins installation , and controller/agent classification can be read by connecting to first pipeline configuration . We will not repeat the server installation in this section.
Git · GitOps All Series · 18 / 24
On this page
First check who reaches Gitea
localhost:13000 in Part 15 was the tunnel address of the administrator PC. If you use localhost on a separate Jenkins agent, it will connect to itself. Prepare your internal DNS and HTTPS or SSH addresses, and verify connectivity from the execution location that pulls the actual code.
The step of reading the Pipeline file may also require access to the controller or SCM-related execution path. The agent does not assume that all connections are completed just because the clone is successful. Check Jenkins’ connection error log to see which node failed.
1. Register the storage read-only key
Register the CI-specific public key as the deploy key in the corresponding Gitea repository and do not grant write permission. In Jenkins Credentials, store the private key as SSH username with private key type and separate the ID like gitea-demo-read. It is advantageous for recovery and audit to not reuse individual workers’ account keys.
In the SSH Host Key Verification setting of Jenkins Git Client, register the host key verified by the administrator or prepare the known_hosts of the execution environment you are using. The option to turn off validation does not allow it to pass. If you use a non-standard SSH port, ensure that the host notation in known_hosts is also in the format [호스트]:포트.
2. Put only the tools your agent needs
The node label in this example is linux-python-git. Your Linux agent must have Git and Python 3, and you specify the same label in your Jenkins settings. There is no need to build directly from the controller or hand over a Docker socket on the production server as build permission.
# Run as the same OS user that executes the Jenkins agent.
git --version
python3 --version
When the environment is ready, write the following Jenkinsfile in the root of the repository: Use greeting.py and test_greeting.py, the same as in Part 17. Even if there is a workflow file for GitHub, Jenkins executes based on this Jenkinsfile.
pipeline {
agent { label 'linux-python-git' }
options {
skipDefaultCheckout(true)
disableConcurrentBuilds()
timeout(time: 10, unit: 'MINUTES')
}
triggers { pollSCM('H/5 * * * *') }
stages {
stage('Checkout') {
steps {
deleteDir()
checkout scm
sh 'git rev-parse HEAD'
}
}
stage('Test') {
steps { sh 'python3 -m unittest discover -v' }
}
stage('Package') {
steps {
sh 'mkdir -p dist && git archive --format=zip --output=dist/app.zip HEAD'
archiveArtifacts artifacts: 'dist/app.zip', fingerprint: true
}
}
}
}
3. Create a Pipeline from SCM task
- Create a new Pipeline job in Jenkins.
- Select Definition as Pipeline script from SCM and SCM as Git.
- Specify the actual Gitea SSH repository URL and
gitea-demo-readcredentials. - Branch Specifier is set to
*/mainand Script Path is set toJenkinsfile. - After saving, manually run your first build.
skipDefaultCheckout(true) prevents automatic checkout and explicit checkout from overlapping. In the one-time workspace assigned to this task, clear the remaining files with deleteDir() and then import the code. Do not specify the path where the shared files are located to the Jenkins workspace.
Verify that git rev-parse HEAD in the log is the intended commit. If the test fails, you should not proceed to the Package step. archiveArtifacts‘s fingerprint is a function for tracking output within Jenkins and is not a substitute for cryptographic provenance signatures.
Polling and webhooks are ways to notify changes.
An example is polling H/5 * * * * to check for SCM changes at distributed time intervals of approximately 5 minutes. It operates after reading the trigger settings in the Jenkinsfile during the first manual build. If speed of notification of changes is important to you, you can turn to the tried-and-true webhook route in Gitea and Jenkins plugins.
Webhooks are event notifications, not file transfers that deliver code. Jenkins still requires authentication to read the repository. We check the incoming URL, secret verification, event range, retransmission and duplicate execution, and do not unconditionally allow the entire private network to unblock Gitea’s internal address access.
This is not the scope of actually executing this Pipeline by launching a new Jenkins controller. The example’s Python test and Git ZIP creation were verified separately. Grammar and SCM operation are based on Jenkins Pipeline grammar, Git plugin, SSH Host key verification.
Previous · [Git and GitOps 17] Add GitHub Actions CI and Stop on Test Failures · Next · [Git and GitOps 19] Plan CD: Approval, Artifact Promotion and Image Digests · Series list and example files



