CODEWITHSUNDEEP
continuous-integrationperforce
anatolyg
anatolyg

Reputation: 28278

Can I track workspace changes in Perforce?

Our Jenkins job downloads some code from a Perforce server, using a pre-defined workspace. It sometimes fails with the following error message:

Client 'xxxx' can only be used from host 'yyyy'.

When I look at the workspace ("client" is an obsolete name for workspace), I see that its settings don't mention host yyyy at all.

I suspect that people (or unknown scripts) change the workspace's settings, do some work and then change them back. If a Jenkins job is scheduled to run during that time, it fails.

How can I determine if I guessed correctly? Are there any logs on the Perforce server which report workspace changes? Maybe some server setting to record all changes to workspaces?

Workspace settings look like something I should be able to track and/or revert using version control; is this really the case?

Upvotes: 0

Views: 115

Answers (1)

Samwise
Samwise

Reputation: 71517

First and foremost, you should set the locked option on the client if you don't want anyone else messing with it (and set its Owner to be the user who runs the Jenkins job, and ensure that this user is password-protected so that nobody else can impersonate Jenkins).

To track changes to client specs, you can set up a spec depot (just create a depot with Type: spec). This will cause every spec update to be saved in that depot as a revision of a text file, e.g. client xxxx will correspond to a text file called //spec/client/xxxx. You can run normal commands like p4 annotate on that file to see its change history, and you can pipe old versions of the file into the current client spec by doing, e.g.:

p4 print -q //spec/client/xxxx | p4 client -i

But again, first and foremost, persistent clients that automation depends on should simply be locked so that they can't be sabotaged (intentionally or unwittingly) by other users.

Upvotes: 3

Related Questions