I am new to ClearCase trigger. My requirements include the following point:
When user is trying to check in a file using CCRC I need to validate the code being checked in using a PMD tool.
So I need to write a trigger which calls this PMD tool (accessble by CC server) and validate the code being checked in and if code is fine, then I can proceed. Otherwise it should throw error.
Also I need to know how triggers are installed.
Since CC server is not on my local and currently in use by other team mates, I think I need to get it on local to test this. Otherwise it will give issue to others if I test it directly there.
How would you address those points?
A good source for "hooks" (called trggier) for CCRC is the IBM article "Writing triggers for the ClearCase Remote Client" (for CCRC 7.x, which is different from ClearTeam explorer 8.x)
The main issue is that you cannot use clearprompt (which is a full clearcase command, not available with a CCRC client).
See this script for an example on how to write a trigger which detects a CCRC environment.
$ppid=$ENV{"CLEARCASE_PPID"};
$taskline = `tasklist | findstr $ppid`;
$taskname = substr ($taskline,0,index($taskline,"exe")+3);
if ($taskname eq "clearexplorer.exe")
{
...
}
else
{
print STDERR $outtext;
}
Related
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?
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.
Cleartool has a command cleartool rmstream to delete a specific stream. But in CCRC there is no corresponding command. From GUI also, there is no option to delete the stream. Anyone has any solution to this? Views can be deleted.
Similarly, for cleartool rmbranch is there any alternative command in CCRC?
Why complete command support is not provided in CCRC, people are not supposed to use CCRC??
From what I can see, this does not seem supported (not from a CTE ClearTeam Explorer even 9.x), so not from IBM Rational ClearCase Web (CCWeb) or IBM Rational ClearCase Remote Client (CCRC)
That means an admin has to delete the stream on the IBM Rational Web Platform (RWP) server side.
Why complete command support is not provided in CCRC, people are not supposed to use CCRC??
Because CCRC is meant to be used by clients, and rmstream/rmbranch are consider "administrative" commands, better done on the server side by admins.
Recently i've came to an issue to configure Last Participant Support on deployed application. I've found some old post about that:
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014090728
On server itself i found how to do it. But with jython or wsadmin commands im not able to find how to do it on application itself.
But it does not help for me. Any ideas?
There is no command assistance available for the action of changing last participant support from the admin console which typically implies there is no scripting command associated the action. And there doesn't appear to be an wsadmin AdminApp command to modify the property. Looking at config repo changes made as a result of the admin console action, the IBM Programming Model Extensions (PME) deployment descriptor file "ibm-application-ext-pme.xmi" for an application is created/modified by the action.
If possible, the best long-term solution would be to use a tool like RAD to generate that extensions file when packaging the application because if you need to redeploy the app, your config changes wouldn't get overridden. If you can't mod the app, you can script the addition of an PME descriptor file in each of the desired apps with the knowledge that redeploying the app will overwrite your changes. The changes can be made by doing something along the lines of:
1) create a text file named ibm-application-ext-pme.xmi with contents similar to this:
<pmeext:PMEApplicationExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:pmeext="http://www.ibm.com/websphere/appserver/schemas/5.0/pmeext.xmi" xmi:id="PMEApplicationExtension_1559836881290">
<lastParticipantSupportExtension xmi:id="LastParticipantSupportExtension_1559836881292" acceptHeuristicHazard="false"/>
</pmeext:PMEApplicationExtension>
2) in wsadmin or your jython script do the following (note in this example the xmi file you created is in the current directory, if not, include the full path to it in the createDocument command) :
deployUri = "cells/<your_cell_name>/applications/<your_app_name>.ear/deployments/<your_app_name>/META-INF/ibm-application-ext-pme.xmi"
AdminConfig.createDocument(deployUri, "ibm-application-ext-pme.xmi")
AdminConfig.save()
3) restart the server
I'm trying to do this:
import groovy.sql.Sql
def sql = Sql.newInstance(
url:'jdbc:sqlserver://localhost\\myDB',
user:'server\user', //this I don't think I need because of SSPI
password:'password',
driver:'com.microsoft.sqlserver.jdbc.SQLServerDriver',
SSPI: 'true'
)
The problem I'm having is that this connection is just timing out. I can ping the machine. I can also connect to the database with Managment Studio logged into my SSPI user (or whatever you call it, I start the Management Studio with a different user)
So I've tried that with my SoapUI as well, started the program as a different user, but I still time out when I initiate the connection. So something is very wrong with my connection string and any help would be appreciated.
P.S. Yes, I don't know what's up with the \ backslashes after the URL to the server, I guess it indicates that it's at the root. If I don't use them I get a message that I'm on the incorrect version.
And then we found the answer..... First of all I had the wrong JDBC driver installed. You need to head over to microsoft to get the real deal:
https://www.microsoft.com/en-us/download/details.aspx?id=11774
Then you need to unpack this one, place the 4 or 4.1 version in your bin directory of SoapUI. (You are apparently supposed to use Lib/Ext, but that doesn't work for me)
Then, since we are trying to use SSPI or Windows Authentication, to connect to the SQL server, you need to place the sqljdbc_auth.dll from the driver/enu/auth folder. This is used in one of your path's or in SoapUI Lib folder. Remember to use the 32 bit dll for 32 bit SoapUI!!! I did not since my system is 64.....
After this, I used this string, but now you have the setup correct, so it should work fine as long as you remember to start SoapUI up using the correct windows user. (Shif-right click - start as different user - use the same user you have started the SQL server with)
Again, I wasn't completely aware of this from the start (yes, total newbie here) and it failed.
Finally, when you have done all this, this is the string that works - and probably a lot of derivatives since the failing part here were the driver and dll.
def sql =Sql.newInstance("jdbc:sqlserver://localhost;Database=myDB;integratedSecurity=true","com.microsoft.sqlserver.jdbc.SQLServerDriver")
I'm using Teamcity to automate (single click) deploys into our QA environment. At the moment content items are being deployed, but the QA guys then have to go and manually trigger a re-publish of the site.
Is there anyway using either TDS, Sitecore Rocks or A.N.Other tool to automate the re-publish at the end of the deploy process.
I know I can configure Sitecore to automatically publish every x minutes, but I would rather leave that deactivated as QA will also be performing load tests and I don't want the scheduler getting in the way.
We have done this by setting up an ASPX on our daily build and QA websites that triggers a publish. The build then has a Powershell call to trigger this. We've done this with CruiseControl, TeamCity, and Team Build.
TeamCity Configuration
The configuration for TeamCity uses an additional build step after you've deployed files and TDS:
Runner Type: Powershell
Step name: Trigger Publish to Web DB
Powershell run mode: x64
Working Directory: [no value]
Script: Source code
Script Source:
$r = [System.Net.WebRequest]::Create('http://myqasite/SomePath/Publish.aspx'); $resp = $r.GetResponse();
Script execution mode: Put script into Powershell stdin with "-Command -" arguments
Publish.aspx
The code for our Publish page is something like this:
string full = Request.QueryString["full"];
// Set up the publish mode
PublishMode publishMode = PublishMode.Smart;
if (!string.IsNullOrWhiteSpace(full) && (full == "1" || full.Equals("true", StringComparison.InvariantCultureIgnoreCase)) ) {
publishMode = PublishMode.Full;
}
using (new Sitecore.SecurityModel.SecurityDisabler()) {
//We need the target database
var webDb = Sitecore.Configuration.Factory.GetDatabase("web");
//source db
var masterDb = Sitecore.Configuration.Factory.GetDatabase("master");
try {
foreach (Language language in masterDb.Languages) {
//loops on the languages and do a full republish on the whole sitecore content tree
var options = new PublishOptions(masterDb, webDb, publishMode, language, DateTime.Now)
{RootItem = masterDb.Items["/sitecore"], RepublishAll = true, Deep = true};
var myPublisher = new Publisher(options);
myPublisher.Publish();
}
}
catch (Exception ex) {
Sitecore.Diagnostics.Log.Error("Could not publish the master database to the web", ex);
}
}
While waiting for an answer I shared the question on twitter, this resulted being given a guiding hand by Stephen Pope (his response)
He suggested using the PowerShell enhancements offered by Sitecore Rocks, it took a while (documentation is thin on the ground) but I have achieved the result I was after :)
As a record of what I found, the following is provided as a potential answer to my own question, though big thanks to Jay S who's solution I would have used if not for this..
Anyway..
Using an additional build step in the Teamcity build, I have the following:
Runner type: Powershell
Step name: Publish site
Powershell run mode: x64
script: Source code
script execution mode: Put script into powershell stdin with "-Command -" arguments
Additional command line parameters: -ExecutionPolicy Unrestricted
Script source:
import-module '.\build-modules\sitecore\sitecore.psd1'; new-psdrive
-name "rocks" -psp SitecoreRocks -root "" -host "%QA.Url%" -usr "%QA.sitecore.user%" -pwd "%QA.sitecore.password%" -databasename "master" -scope "Script"; set-location rocks: Publish-SCDatabase;
The magic happens within the Publish-SCDatabase commandlet which when you run Get-Help shows a bunch of parameters, it turns out that only two of the parameters are usable -Name and -Mode
Finding documentation beyond the vs-plugins link above was impossible, so a bit of .net reflection and a good dose of patiense showes that the parameters have the following options:
-Name The name of the database to run the publish against (default is the psdrive database
-Mode Sets the publish mode of the comandlet with the following options available:
0: Republish
1: Incremental
2: Smart
3: Rebuild
Of course better documentation, and possibly additional info via the Get-Help commandlet would be nice.. if the rocks project was open source, I may well have forked the project to generate the additional help.
Now that there are two very good solutions to this question, I will let peoples votes decide on which is the best answer, in a few days I will check the votes and mark the most voted as the accepted answer.
Whist these are both good solutions (the custom aspx and the Powershell via Rocks one), they both have some shortcomings.
Custom aspx page. Unless you "go to town" on your C# solution for publishing, in offering a very sophisticated way to change publishing targets, Root nodes and other options (e.g. smart, incremental), and allowing for invocation of these options in as flexible manner as possible, you would risk having to change your code to change deployment strategies periodically. The comment by Richard R below the Rocks answer concedes that. Contrast that with some kind of scripted solution. The fact it wouldn't be compiled code lends itself to being chopped and changed, and even proliferating into lots of different scripts for different purposes.
Powershell via Rocks. Again there are shortcomings in terms of customization. You are limited to what commandlets (and ultimately CRUD operations) are supported by that particular implementation. Not to mention it being closed source and having limited documentation.
I probably need to elaborate a little about the use cases I have in mind that may need to be catered for. What if it is particularly important for us to publish only parts of the content tree on deploys (aspects like /templates, /system, /layouts)? In our deployments we have huge /content and /media library sections so being more granular about what gets published for certain deployments is essential to expedite deploys. Now, whilst it's perfectly feasible to create your own /Publish.aspx page which will specify the Root items and do these (deep) publishes for you, it would be much more elegant to do it via some kind of script. Not only that but consider the myriad other operations you may wish to automate on scripted deployments and environmental set-up such as adding content, applying workflows e.t.c.
Contrast both of these with Adam Najmanowicz's Powershell Console/Extensions. By allowing you to develop powershell scripts within sitecore, you can effectively create whatever you wish to by way of a scripted solution and even invoke it from an external tool in order to make that a step in a CI server or orchestrator:
http://blog.najmanowicz.com/2011/12/19/continuous-deployment-in-sitecore-with-powershell/