Git untracked files in commit after the first execution of the job

We have a job that needs to be executed every 30 minutes to retrieve some changes done through the UI of a SF org since the previous execution.
Then, it captures all the changes in our GH repository.

The job works fine the first time it is executed. But from that moment onwards, every time it is executed, the retrieval works as expected but we receive the following error message from the commit line:

Untracked files:

  • (use “git add …” to include in what will be committed)*
  • …/SF Prod (GH)@tmp/*
    nothing added to commit but untracked files present (use “git add” to track)

SF Prod (GH) is one folder in the repository, but it doesn´t have the @tmp suffix. It´s like the suffix Jenkins uses for workspaces, but there is nothing like that in the repository.

We also have some other jobs that make almost the same thing (same actions but related to different SF components) daily, and they have been working fine for a long time.
The only difference with this new job is the scheduled time. Old jobs are executed once a day, and the new process is executed every 30 minutes. There are no concurrent executions (the execution takes less than 20 minutes) and the job also includes the disableConcurrentBuilds() to prevent that kind of conflict.

Also, the new job is working fine the first time it is executed, so the logic is fine. If we remove the trigger in the job to not be executed automatically, and then we build it again manually, it also works as expected. It is when the job is automatically built when the issue happens.

What could be the root cause of this issue?

Thanks in advance

It is normal for jenkins to create auxillary folders (@tmp are coming from pipeline exectutions) to e.g. check out the repo to get the Jenkinsfile. Just use a .gitignore file to ignore such folders or checkout your working dir as a subdirectory.

1 Like

Thank you Björn for your help.

I don´t know why it is happening with this process and not with the other one that is doing almost the same, but once I included the @tmp names in the .gitignore file, it is working as expected.

Javier Carvajal