Commit and Push in Job

A job can commit generated files and push them back to OneDev. The default checkout credential only has read permission for the current project, so configure a credential with code write permission first.

1. Create an access token with code write permission on the destination project. Branch protection rules still apply.

2. Open Settings → Build → Job Secrets, add a secret named push-token, and store the token as its value. Authorize it for the branch whose jobs need it, for example on branch "main".

3. In the job's Checkout Code step, select HTTP(S) for Clone Credential and push-token for Access Token Secret:

   - !CheckoutStep
     name: Checkout with write credential
     cloneCredential: !HttpCredential
       accessTokenSecret: push-token
     withLfs: false
     withSubmodules: false
     condition: SUCCESSFUL

4. Add a Command step in an environment with Git installed. OneDev checks out the build commit, so fetch the destination branch and check it out before committing. This example writes the current build number:

   set -eu
   git config user.name "Build Bot"
   git config user.email "build@@example.com"
   
   git fetch origin main
   git checkout -B main FETCH_HEAD
   
   printf '%s\n' '@build_number@' > build_number.txt
   git add build_number.txt
   if git diff --cached --quiet; then
     exit 0
   fi
   git commit -m "Update build number"
   git push origin HEAD:refs/heads/main

   Replace main with your destination branch. The doubled @@ escapes a literal @ in interpolated job commands. These Git identity settings apply only to the job's checkout.

   The remote URL must be reachable from the command environment. For local Docker Desktop testing, if origin uses host-local localhost, set a container-reachable URL before fetching, for example:

   git remote set-url origin http://host.docker.internal:6610/my-project

   Use the appropriate URL for your installation. Concurrent branch updates can cause a non-fast-forward rejection; resolve that conflict instead of force-pushing.

5. If the job runs on branch updates, exclude generated files under Triggers → Branch update → Touched Files to prevent the pushed commit from triggering the same job again:

   triggers:
   - !BranchUpdateTrigger
     branches: main
     paths: '** -build_number.txt'
     userMatch: anyone

   Here ** includes files and -build_number.txt excludes the generated file. A commit changing another included file still triggers the job, even if it also changes the generated file.

Run the job and inspect both the build log and the destination branch. In this example, the HTTP checkout succeeded and the command pushed a new commit:

The generated-file-only commit should not start another build. Confirm the trigger still works by changing an included file; this distinguishes a working exclusion from a disabled or invalid trigger.