We encountered an unexpected and potentially dangerous behavior when manually
running a job from the project Files page.

We are using OneDev 16.5.7.

A user had the Files page for the master branch open in a browser tab. While
the tab remained open, several newer commits were pushed to master. About
20 minutes later, the user manually started a deployment job from the build
status dropdown on that page without refreshing it.

At that time, master pointed to:

  efcb603                                                                                                                                                                        

However, the resulting build used:

  refName: refs/heads/master                                                                                                                                                     
  commitHash: 01b0b916050fba4323e1905e82415e9d3e95c1c2

The older commit 01b0b91 was the commit displayed when the browser page had originally been loaded.

There was no indication in the job dropdown or confirmation flow that the job would run against an outdated commit rather than the current head of master.

This caused our deployment job to deploy an older Helm configuration and prune Kubernetes resources that had been introduced by the newer commits. We have restored the affected deployment, but the same behavior could cause more serious service or data loss for deployment jobs.

How to reproduce

1. Open the Files page of a branch.
2. Advance the branch from another session by pushing one or more commits.
3. Without refreshing the original browser tab, manually run a job from the build-status dropdown.
4. Inspect the commit hash of the resulting build.

The job appears to use the commit resolved when the Files page was loaded, while still recording the branch as its ref.

We understand that OneDev intentionally supports running jobs for historical commits. However, when starting a job from a branch view, we would expect either the current branch head to be used or a clear warning that the branch has moved and the job will run against an older commit.

Could you please confirm whether this behavior is intended? If it is, we believe the commit being executed should be clearly shown before the job is submitted.

For reference, we had a brief look at the OneDev 16.5.7 source code. In ProjectBlobPage, the branch revision appears to be resolved and stored as resolvedRevision when the page is created. This captured object ID is later passed to CommitStatusLink, then to RunJobLink, which submits it as commitId together with the branch refName.

Relevant locations:

• ProjectBlobPage.java: branch resolution https://github.com/theonedev/onedev/blob/v16.5.7/server-core/src/main/java/io/onedev/server/web/page/project/blob/ProjectBlobPage.java#L234-L239
• ProjectBlobPage.java: construction of CommitStatusLink https://github.com/theonedev/onedev/blob/v16.5.7/server-core/src/main/java/io/onedev/server/web/page/project/blob/ProjectBlobPage.java#L904-L913
• RunJobLink.java: submission using the captured commitId and refName https://github.com/theonedev/onedev/blob/v16.5.7/server-core/src/main/java/io/onedev/server/web/component/job/RunJobLink.java#L156-L158

This seems consistent with the behavior we observed: the page retains the commit resolved at page-load time even though the branch ref has subsequently advanced. We also compared these areas with the current main branch and did not notice a relevant change.

Thanks in advance!

Best regards, Alex