I've created OR split in AEM workflow to check the asset type with the branches ie image, video and pdf.I'm using following ECMAScripts for the branches
Image branch
if(format.equalsIgnoreCase('image')
return true;
video branch
if(format.equalsIgnoreCase('video')
return true;
doc/pdf branch
if(format.equalsIgnoreCase('pdf')
return true;
questions
even after success in first case its going to other 2 cases, is it supposed to do that.
in case of default branch, its always going to default branch no which asset type.
in case of no default branch, its always going to first branch even in case of pdf/video.
Related
Our application needs to use different merge strategies when fetching / merging with JGit. For instance, for any files in conflict that are JSON files, we want to revert any local changes and get THEIRS. If they're not JSON files, we want to keep local changes and merge, even keeping the conflict markers if there are conflicts. However, no matter how I set the merge strategy, I get a CheckoutConflictException (which stops the merge) even if normal command-line git would have done the merge. What am I doing wrong?
public String update() throws Exception {
// We fetch manually and do a dry-run merge to catch any conflicts, so we can reset them
fetch();
Ref fetchHead = this.repo().getRepository().findRef("FETCH_HEAD");
try {
MergeResult mergeResult = this.repo().merge()
.setStrategy(MergeStrategy.RECURSIVE)
.setCommit(false)
.setFastForward(MergeCommand.FastForwardMode.FF)
.include(fetchHead)
.call();
} catch (CheckoutConflictException cce) {
List<String> conflicts = cce.getConflictingPaths();
if (conflicts != null && conflicts.size() > 0) {
for (String file : conflicts) {
if (file.endsWith(".json")) {
revert(Paths.get(file));
}
}
}
}
/// ... and now that we've reverted any conflicted JSON files, we can try the merge for real
MergeResult mergeResult = this.repo().merge()
.setStrategy(MergeStrategy.RECURSIVE)
.setCommit(true)
.setFastForward(MergeCommand.FastForwardMode.FF)
.include(fetchHead)
.call();
return mergeResult.getMergeStatus().toString();
}
I was able to get the behavior I wanted using stashCreate() and stashApply(). Specifically, stashCreate() to stash any changes left after reverting any JSON files, then using PullCommand (not MergeCommand) to pull any new changes, then using stashApply() to apply any stashed local changes. I tested it with no conflicts, conflicts in JSON files, conflicts in other files where different parts of the file were changed between local and remote, and other files where the same line(s) were changed. It worked in all of the above cases.
When I use libgit2 to update data, pull seem to create unnecessary short-term branches and merges which are a headache to resolve. and each merge produced a new oid, so there should be a function to determine if a merge commit is needed before the merge commit. wondering if it is a good practice, then what is the best way to do it?
If you want to analyze whether a merge is needed between two branches, or if instead it is fast-forwardable, use the git_merge_analysis function:
git_merge_analysis_t analysis;
git_merge_preference_t preference;
int error = git_merge_analysis(&analysis, &preference, repo, merge_heads, merge_head_len);
if (analysis == GIT_MERGE_ANALYSIS_FASTFORWARD) {
/* You can simply do a fast-forward */
} else {
/* You need to do a true merge */
}
You may wish to examine the preference to know whether the user has asked to never fast-forward.
Im trying to write a stash plugin that will iterate through the commits in a change set pushed to stash in a Pre Receive Repository Hook.
The API passes a Collection of refChange in the onReceive method.
public boolean onReceive(RepositoryHookContext context, Collection<RefChange> refChanges, HookResponse hookResponse)
if I make 3 commits then push I get one RefChange which looks like this
refId = refs/heads/master
fromHash = ded3e4583653f14892cc3e8a898ba74ee75e1a58 // First Commit in change set
toHash = ae017dcdadf7ca69617fb05f6905cccfe2aa4229 // Most recent commit
type = "UPDATE"
Id like to get a collection of all the commits so that I can get all the commit messages.
I'm looking at com.atlassian.stash.commit.CommitService getCommit and getCommits. I think I need to getCommitsBetween but can't quite figure out how to crate the GetCommitsBetween parameter needed from the RefChange I have.
Am I even heading down the right path here?
Even though the CommitsBetweenRequest page on the Atlassian Stash API documentation is one of the few pages with an explanation, it took some trial and error to figure this out. GetCommitsBetween works but here's the trick...
Set the commitsBetweenBuilder.exclude to the starting commit in the change set and commitsBetweenBuilder.include to the ending commit hash.
CommitsBetweenRequest.Builder commitsBetweenBuilder = new CommitsBetweenRequest.Builder(context.getRepository() );
commitsBetweenBuilder.exclude(refChange.getFromHash()); //Starting with
commitsBetweenBuilder.include(refChange.getToHash()); // ending with
PageRequest pageRequest = new PageRequestImpl(0,6);
Page<Commit> commits = commitService.getCommitsBetween(commitsBetweenBuilder.build(), pageRequest);
//TODO: handle Pages
for (Commit commit : commits.getValues()) {
hookResponse.out().println("Message = " + commit.getMessage() + "\n");
}
I wasn't able to get the dependency injection working for the CommitService. Spring for some reason wasn't able to find it, when trying to run in locally ???
I did getting it working using the component locator.
CommitService commitService = ComponentLocator.getComponent(CommitService.class);
I have a dexterity content type in Plone 4.2.4. The versioning works fine with the default workflow for this content type, although it is not a workflow shipped with plone, but a custom made.
However, when I enable a second workflow for the same type, everything but the versioning works fine.
additional permissions managed by the second workflow are working
The state changes are working
The difference:
I used different state_variable names for the workflows, which seems to make sense, to have a catalogable field for the state of the second workflow.
I've tried to use the same state variable name, but that didn't help. I have the workflow variable review_history also set in the 2nd workflow and sufficient permissions in the context.
I am (mostly) shure, that I got the permission concept, but I have no clou, how permissions get calculated, when multiple workflows are involved.
Any idea, why the second workflow does not leave a trace in my content types history?
Thanks very much in advance.
Udate
I've reordered the workflows as Ida Ebkes suggested and did see, that all transitions from the 2nd workflow get stored properly. So it seems to be an issue with the historyview.
Since these workflows indeed describe concurrent behaviors of a content type, I really would like to stick with separate workflows and ideally different workflow state variables and catalog indexes.
What I now think needs to be done, is to tweak the historyview.
Here is how I did it. It works for plone 4.2.4 at least.
Since the problem was a display problem, I just had to tweak my historyviewlet. Therefore, I created a folder named viewlets in my product root and created a __init__.py and a configure.zcml file. Then i copied content_history.pt, history_view.pt, review_history.pt and content.py from plone/app/layout/viewlets/ (omelette) to the newly created folder.
The configure.zcml contains two view registrations:
<browser:view
for="*"
name="my-contenthistory"
class=".content.ContentHistoryView"
permission="zope2.View"
/>
<browser:page
for="*"
name="my-historyview"
template="history_view.pt"
permission="zope2.View"
/>
Furthermore, I copied the whole WorkflowHistoryViewlet class from content.py to a different class name. TransferHistory in this case. Then I changed mostly the part that corresponds to the workflow state variable, which was not review_state, but transfer_state. I further found that the initial usage of the 2nd workflow creates also a created entry in the history of the 2nd workflow, that I just filtered .
transfer_history = [x for x in transfer_history if x['action'] != None]
The I corrected the view name in history_view.pt to my new view name.
<div tal:replace="structure here/##my-contenthistory">Content History</div>
Finally, I added my class as parent to the ContentHistoryViewlet class in content.py
class ContentHistoryViewlet(WorkflowHistoryViewlet, TransferHistoryViewlet):
index = ViewPageTemplateFile("content_history.pt")
#memoize
def getUserInfo(self, userid):
[...]
def fullHistory(self):
history = self.workflowHistory() + self.revisionHistory() + self.transferHistory()
if len(history) == 0:
return None
history.sort(key=lambda x: x["time"], reverse=True)
return history
and registered the .zcml in the products configure.zcml
<include package=".viewlets" />
Then I modified content_history.pt and also changed the definition of action_id in the upper part of the file.
[...]
action_id python:item['action'] or item.get('review_state', False) or item.get('transfer_state', False);
[...]
After rebooting the monster and a product reinstall, all state changes from both workflows are shown in the my-historyview.
I need to send an email on completion of a build in TFS 2010 which details the work items associated with check-ins that have been compiled as part of this build. This works no problem via use of the associatedChangesets variable available in the build workflow.
However, in a production situation, we will merge changes from our Development branch into a Release branch. At this point, the build considers there to have only been one change - which is the aforementioned merging of Development into Release. Obviously this is fairly useless as we need to find out which changes where made in the branch that was merged in, and the work items associated.
Does anyone know how to accomplish this using the TFS 2010 API? It seems to be fairly poorly documented from an API perspective. I know you can expand the merge history node in VS2010 but obviously this is no good as this data needs to be collected programatically so a report email can be sent.
OK... I think I found a solution to this although it's clunky and truth be told I'm not exactly sure how it works. But here goes - maybe it will point someone in the right direction.
var associatedWorkItems = new List<WorkItem>();
//Passed in from the build workflow (this variable is available under the 'Run On Agent' sequence as 'associatedChangesets'
IList<Changeset> associatedChangesets = context.GetValue(BuildAssociatedChangesets);
if (associatedChangesets.Count > 0)
{
var projectCollection =
new TfsTeamProjectCollection(new Uri("http://localhost:8080/tfs/DefaultCollection"));
VersionControlServer versionControlServer = projectCollection.GetService<VersionControlServer>();
foreach (var changeset in associatedChangesets)
{
//In order to view the individual changes, load the changeset directly from the VCS.
Changeset localChangeset = versionControlServer.GetChangeset(changeset.ChangesetId);
foreach (Change change in localChangeset.Changes)
{
//Find out what was merged in.
ChangesetMerge[] mergedChangesets = versionControlServer.QueryMerges(
null,
null,
change.Item.ServerItem,
new ChangesetVersionSpec(localChangeset.ChangesetId),
new ChangesetVersionSpec(localChangeset.ChangesetId),
null,
RecursionType.Full);
//Extract work item information from changesets being identified as merged.
foreach (var changesetMerge in mergedChangesets)
{
Changeset actualChange = versionControlServer.GetChangeset(changesetMerge.SourceVersion);
foreach (WorkItem item in actualChange.WorkItems)
{
if (!associatedWorkItems.Exists(w => w.Id == item.Id))
{
associatedWorkItems.Add(item);
}
}
}
}
}
}
Don't ask me exactly how QueryMerges works but all I'm doing here it saying show me what what merged as a part of a changeset checked in. You'll notice that the parameters ChangesetVersionSpec are the same - this means we're just looking at merges from this one changeset.
You'll get back an array of ChangesetMerge objects from QueryMerges(). In the ChangesetMerge class there is a property called SourceVersion - this is the ChangesetId of the original changeset merged in. Once we've got that we can use the VersionControlServer.GetChangeset() method to load the individual set and extract the WorkItem. This is then added to a list of WorkItems which can be manipulated in any way you want (in my case an email). I also used the .Exists() check to make sure the same WorkItem doesn't get recorded twice.
Note that even though you have the collection associatedChangesets from the build workflow, for some reason (for me at least), the Changes[] property inside associatedChangesets was never populated (hence loading each individual changeset using the VersionControlServer.GetChangeset() method as this seems to actually populate all the fields we need.
Like I say, 1. this is a clunky solution (lots of looping - some of which is probably unecessary), 2. I don't fully understand how this works although it seems to produce the required results - I came to this conclusion by doing a lot testing and debugging) and finally - it's the best I could come up with based on the woeful documentation provided by Microsoft.
Hope it helps someone!