Is it possible to use the Jenkins UCM clearcase plugin with existing view either snapshot or dynamic view without creating a view with each build request. Is there another way to achieve this? Thank you for all replies.
The Jenkins ClearCase UCM plugin mentions:
The plugin will automatically create a snapshot view in a folder named 'view' in the root of the job's workspace
We us a separate view per job, per client, which allows us to reuse views in a context the only changes very little between builds.
The plugin creates a separate read/only development stream and snapshot view for every self polling job on every slave that executes the job.
The stream and view is created the first time the job is executed on the slave and then reused by successive job executions.
That means it does not create a different view per build, but reuse the current one.
Related
I am using the FileSystem trigger to monitor whether the code in a folder changed (from git repo)
My thought is
use normal Poll SCM every 2 minutes
check the actual downloaded source folder in question for changes after step 1 polls the every 2 minutes.
Questions:
Is the flow correct? Should it poll SCM every 2 minutes, and then the actual folder every 2 minutes? Should it directly poll the folder in the repo on bitbucket/github? Currently the build is being built every time the project fires - it bypasses the folder check.
I tried setting the folder path to %WORKSPACE%/MyProjectToMonitorFolder and the
[FSTrigger] - Monitor folder logs said that it could not find the folder. If I hardcode the actual full folder path as in the image then the folder and changes are found. How can I incorporate %WORSKPACE% into the folder path?
Both triggers serve very different use cases and usually don't go together. I assume what you want to achieve is a trigger to your job that will run it whenever a specific folder has changes in your Git repository.
You can achieve it by first configuring you SCM Git build stage to only monitor a specific folder in your repository, it will eliminate the need for using the file system trigger as it will only trigger the job when the configured folders have changed. You can find more info in the Official Documentation under the Polling ignores commits in certain paths section.
You can also check out This Answer for more info.
In addition it is highly recommended to move from a scheduled SCM pulling mechanism to a hook based Git trigger that will trigger your job whenever new code is pushed to the repository and will avoid the need to constantly check for changes, see This This Answer for more info on the git hooks configuration.
Furthermore every major Git repository manger (GitHub, Bitbucket, Gitlab...) has dedicated integration Jenkins plugins for git hooks and other operations - so you can use one of them to make your integration easy.
I am trying to understand how long ClearCase operations take after performing the add to source control operations.
If I am working through a CCRC snapshot view and I add a file to source control, how long will it take for the changeset to be updated with the new line, and how long until the operation completes will the new file be available under a dynamic view pointing to the stream that the file was checked into?
Is there any way to speed up that process by invoking a manual update of the dynamic view or something?
Regards,
Andrew
how long will it take for the changeset to be updated with the new line
As soon as you checkout a file, selecting an activity, it will update the chenge set of said activity immediately.
A dynamic view would reflect that file only after you check in (through your web snapshot view in CCRC), and that update would also be near instantaneous.
To speed up, you can refresh the dynamic view, or do a cleartool ls in the directory you want to see updated.
In each case, when you are doing a checkout or a checkin through CCRC, you are posting an http request to the CCRC server which in turn complete the operation with the ClearCase Vob/View server.
So once the checkout/checkin is completed, any other ClearCase view (CCRC or not) would be ready to reflect the changes.
The only part which takes time is the communication between the CCRC client and the CCRC server. That server being usually on the same LAN as the ClearCase server, the ClearCase command itself executes fairly quickly.
"fairly quickly" turned out too slow for the OP's need: a postop trigger on checkin.
That trigger use a ClearCase dynamic view on the server side, and has to introduce a sleep on the element checkin (on mkelem) in order for the second call of that trigger (on the parent directory being checked in) to properly detect the new created file.
Theoretically, it should be instant. As soon as the add finishes, the dynamic view should see the new file. In reality, it might take longer due to the nature of ClearCase and its view processes.
Every view has a process running on the view server (local or remote), and this process needs to query the VOB server to get the changes.
In our ClearCase environment, we see many lags that are probably the combination of a loaded server and network traffic.
Bottom line - should be quick (seconds), but not instant. If it takes longer, you should try and see what might be slowing the processes down.
Is it possible to simulate multi developer scenario with RTC source control so that when I make code changes I can test accepting change sets for example. This is just so I can test a multi developer environment but using just one user.
I've tried creating multiple Eclipse workspaces, and loading the same project area into each Eclipse workspace. Using this method I am unable to accept change sets as RTC source control will just ask me to resync my workspace once I make a change in work Eclipse workspace:
It seems the only method of accepting incoming changes is to
1. Right click on the stream from within 'Pending CHanges' view
2. Select load
3. Select following option :
Make sure you use the Stream (ie make sure you don't deliver directly to another repo workspace simulating another user)
(Note: this is entirely different in ClearCase, where the "out of sync" can happen between the configuration of an UCM view and the one of a Stream after a rebase)
If you create different repo workspace (loaded in different Eclipse workspace), this can cause some confusion when used within the same Eclipse instance.
As said in this thread
repository workspaces are meant to isolate changes - being your private stream.
There is no automatic accepting of changes so you are in full control of what flows in. You can also run private builds on them. that is the whole idea.
If you want to run several repository workspaces with shared code you should use a Stream I think.
The clean repo workspace would be used to accept the changes you decide to deliver to your stream.
So you are trying to use a repository workspace as a stream. While they are almost identical, I am not sure about how they would react to changes delivered to them. Especially while being loaded.
You should use two Eclipse instances. I am concerned about having the same eclipse projects loaded multiple times in the same sandbox and the same Eclipse
That "confusion" is explained in the same thread:
This is expected behavior.
When you change WS1 by delivering to it, the content you've loaded to disk for WS1 isn't updated. So you have to reload.
For this reason, you are not allowed to deliver to other user's workspaces. You can't alter someone's workspace but you can alter your own because you would know why it went out of sync.
Check out point 7 and 10 of "Good practices and key workflows for Rational Team Concert Source Control users".
Note: the article "Loading Content from a Jazz Source Control Repository in Rational Team Concert 2.0" (also valid for RTC3.0) mentions in the section "Reloading Out-of-sync Shared Folders" a similar advice than the one given by the OP:
The local workspace can become out of sync with the remote workspace due to a couple of reasons:
The remote workspace is loaded multiple times and changes have been checked in or accepted from another client session.
An error was encountered during an operation (e.g. Accept) that modifies both the local and remote workspaces.
When the local workspace became out of sync with the remote workspace in RTC 1.0, the user was forced to run the Load wizard and reselect the folders that needed to be reloaded.
In RTC 2.0, this new option will automatically select the out of sync folders and reload them so they are no longer out of sync.
Also new in RTC 2.0 is an indication in the Pending Changes view that there are projects out of sync, as shown below.
Clicking on the Reload out of sync link in the Pending Changes view will open the Load wizard.
The reload option will be selected by default and clicking next will then allow you to select which folders to reload.
As you can see in the following screen shot, all the projects in the Foundation component are out of sync and need to be reloaded.
Clicking Finish will reload these folders and bring them back in sync.
Also the thread "How to handle project out of sync " provides an interesting illustration of that mechanism (even though it isn't exactly your situation).
Consider a single stream UCM project in ClearCase.
Each developer works in her own snapshot view on the integration stream of the project.
According to the ClearCase documentation when a developer completes an activity, the changes made by the activity become visible to the rest of the developers.
When developer A completes an activity P, are the changes of P immediately visible to developer B and C?
Or do B and C have to refresh their snapshot view in order to actually see the changes?
For a snapshot view (UCM or not), you always have to "cleartool update" your view in order to see the changes committed by your colleagues.
Note: the notion of "completing an activity" might suggest that you are actually using ClearCase with ClearQuest (which will check-in all checked out files associated with an activity, when the related ClearQuest work item is "completed").
This is valid for single-stream UCM projects as well as multi-streams: every time you have several snapshot views on a single stream, you need an update to see your colleagues' commits.
I am using eclipse clearcase remote client. Everytime i wish to check out the file, i am going into the long branch.
Is there any way to find a file directly in the root like searching?
If you are using CCRC, you are using a snapshot view, which have an config spec specifying:
what you are selecting (this is the part you need to adjust to check out the right version in the right branch)
what you are loading on your disk.
As mentioned in this comparison matrix between CCRC and other ClearCase instances,
CCRC can only search the local copy area’s database for checkouts, hijacks, view privates.
I would recommend making a second CCRC web view, and make some tests on that view (with a small set of files loaded).