Hi Steve, Thanks for your reply, I have added comments below...
> [Steve RE: Credentials] > The new plugin extends Jenkins Credentials into two new types. Perforce > Password credential and Perforce Ticket credential; these both support SSL > and P4TRUST finger prints. I did look at the password and SSL credentials, > but Perforce has some specifics P4TICKETS etc.. > > Sounds like you've implemented one too many. > > You should not be implementing a user+pass credential type at all. The ticket > credential type is fair enough... In principle (I have not looked at your > code mind) I may have taken the use of your credentials too far, but it makes a very neat solution for Perforce authentication. We can even extend the pattern to Perforce cert based SSO later. Do try it out if you have a moment or I can send a screen shot if you are interested. We try to discourage the user of passwords from a security perspective and encourage our users to use session tickets. Tickets are bound to a connection, this is why I store the Perforce connection. I also allows users to test the credential with the validate button. > I had tried to make the SCM polling more efficient and letting Perforce > manage it's own workspaces, after all this is what Perforce was designed to > do. I was not aware of the 'SCM-API', is there any docs/guide like: > > https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture > > No docs yet. It's needed to allow multi-branch support ala literate project > type (though no limited to literate) > > Subversion, git and hg all have implementations of the SCM-api. > > It impacts polling as you want to expand the scope of what you find info > about, so eg > > * subversion maintains a map of latest revisions of various paths... This map > will in future be used to reduce the amount of polling that jobs need... At > present only literate takes advantage of the map (waiting until I feel the > credentials support has bedded down) > > * git and hg maintain a local checkout which (git) can be used / (hg) is used > to speed up checkout on slaves and reduce the amount of querying > > Once SCM-api us fully integrated these plugins will have effectively much > more performant polling whereby eg push notifications get merged into local > stores so that 99% of polling operations are served from a local cache (fed > by both other jobs off same repo and push notifications) I'll take a look at your code/implementations when I'm back in the office, so I can understand if this polling is needed this way in Perforce. Perforce is unique in the way that stores (server side) a lot of information about what is in a client's workspace. Kind regards, Paul -------------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Perforce Software. Finally, the recipient should check this email and any attachments for the presence of viruses. Perforce Software accepts no liability for any damage caused by any virus transmitted by this email. Perforce Software UK Ltd is registered in England and Wales as company no. 3816019 at the following address: West Forest Gate, Wellington Road, Wokingham, RG40 2AT, UK -------------------------------------------------------------------------------- -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
