I have two branches: master and develop. At the starting point the develop branched from master
Now I try to make two releases in row:
First time I did "mvn jgitflow:release-start", "mvn jgitflow:release-finish". It has successfully create a release tag and causes no problem
Second time I did the same ("mvn jgitflow:release-start", "mvn jgitflow:release-finish"). This time I get a merge conflict error in my .pom files
Third time I made a merge commit from develop to master. After that I did "mvn jgitflow:release-start", "mvn jgitflow:release-finish". This time it has successfully done.
The problem is (2). I always get merge conflict error here if not doing (3)
Is there any way how to avoid manual merges (3) between master and develop branches to make a release with jgitflow-maven-plugin?
<plugin>
<groupId>external.atlassian.jgitflow</groupId>
<artifactId>jgitflow-maven-plugin</artifactId>
<version>1.0-m5.1</version>
<configuration>
<flowInitContext>
<masterBranchName>master</masterBranchName>
<developBranchName>development</developBranchName>
<featureBranchPrefix>feature-</featureBranchPrefix>
<releaseBranchPrefix>release-</releaseBranchPrefix>
<hotfixBranchPrefix>hotfix-</hotfixBranchPrefix>
<versionTagPrefix>version-</versionTagPrefix>
</flowInitContext>
<noDeploy>true</noDeploy>
<squash>true</squash>
<scmCommentPrefix>[RELEASE] </scmCommentPrefix>
</configuration>
</plugin>
Related
I'm using Liquibase with gradle in order to apply database changes.
I have three activities in runList:
runList='stop_job, execute_changes, start_job'
It works fine in case that I don't have any exception, but if something fails on the second step (execute_changes) it stops there and does not execute "start_job" activity.
Is it possible to introduce something like a fallback activity or "finally" block?
You could use failOnError:false. It defines whether the migration will fail if an error occurs while executing the changeset. Default value is true.
Does anyone knows how the commits from a release are determined?
From my tests it resulted that is taking into the consideration the last commit even if that commit was associated with a build was triggered couple of builds ago.
In the below screenshots it's displayed that all three last releases are using changeset 47512 which quite confusing for me:
Release 10-01:
Release 09-01:
Release 08-01:
Release shows the difference between w.r.t last release. While showing the difference, it shows the difference between the builds used in the two releases.
Let me explain with some example. Say there are Release1 (with buildA having commit A,B,C) , Release2(with buildB having commit D,E,F) and Release3 (with buildC having commit G,H,,I) and Release4 (with buildC having commit G,H,I).
Here commit tab of Release3 will show the diff w.r.t Release2 and it should show G,H,I.
Similarly commit tab of Release4 will show the diff w.r.t Release3 and it should show 'No diff' as build used is same.
I would like to enforce the execution order of sibling dependencies. Let's assume we have the following top-level targets:
add_custom_target(test_all)
add_custom_target(test_coverage)
add_custom_target(test_coverage_zero)
add_custom_target(test_coverage_collect)
I'm using test_all to execute unit tests (and possibly build them and their dependencies). test_coverage should execute test_coverage_zero, then test_all, and finally test_coverage_collect. test_coverage_zero will cleanup leftover coverage data from a previous run of test_all, while test_coverage_collect uses the current coverage data and produces some kind human-readable output. The reason for this setup is to allow test_all to be executed without actual coverage data processing. On the other hand test_coverage needs to execute test_all to produce coverage data.
[Detail: I'm using gcov/lcov for the coverage data and added custom commands to test_coverage_zero and test_coverage_collect for the actual processing.]
I've setup the following dependencies to achieve this behavior:
add_dependencies(test_coverage test_coverage_zero test_all test_coverage_collect)
That does not work. The actual execution order is test_all, test_coverage_zero, and test_coverage_collect, which removes the coverage data before the collection step.
My question: How do I enforce the order of target dependencies (on the sibling level) in CMake?
Looks like the answer is:
add_dependencies(test_all test_coverage_zero)
add_dependencies(test_coverage_collect test_all)
add_dependencies(test_coverage test_coverage_zero test_all test_coverage_collect)
However, removing either test_coverage_zero or test_all from the last dependency will also not work, even though there's a clear dependency chain test_coverage<-test_coverage_collect<-test_all<-test_coverage_zero.
I have a waf task that is running a msbuild in order to build a project but I do want to run this only if last execution was not successful.
How should I do this?
Store in your build.env.MS_SUCC = 1 and retrieve the value from the previous build (for the first time you naturally have to check if the dict item MS_SUCC exists)
I've set enable_broker on my SQL Server 2008 to use SQLDepndency
I've configured my .Net app to use Syscache2 with a cache region as follows:
<syscache2>
<cacheRegion name="BlogEntriesCacheRegion" priority="High">
<dependencies>
<commands>
<add name="BlogEntries"
command="Select EntryId from dbo.Blog_Entries where ENABLED=1"
/>
</commands>
</dependencies>
</cacheRegion>
</syscache2>
My Hbm file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
<class name="BlogEntry" table="Blog_Entries">
<cache usage="nonstrict-read-write" region="BlogEntriesCacheRegion"/>
....
</class>
</hibernate-mapping>
I also have query caching enabled for queries against BlogEntry
When I first query, the results are cached in the 2nd level cache, as expected.
If I now go and change a row in blog_entries, everything works as expected, the cache is expired, it get's this message:
2010-03-03 12:56:50,583 [7] DEBUG NHibernate.Caches.SysCache2.SysCacheRegion - Cache items for region 'BlogEntriesCacheRegion' have been removed from the cache for the following reason : DependencyChanged
I expect that. On the next page request, the query and it's results are stored back in the cache. However, the cache is immediately invalidated again, even though nothing has further changed.
DEBUG NHibernate.Caches.SysCache2.SysCacheRegion - Cache items for region 'BlogEntriesCacheRegion' have been removed from the cache for the following reason : DependencyChanged
My cache is constantly invalidated every subsequent time with no changes to the underlying data. Only a restart of the application allows the cache to operate again - but only the first time the data is cached (again, the first dirtying of the cache, causes it to never work again)
Has anyone seen this problem or got any ideas what this could be? I was thinking that syscache2 needs to handle the SQLDependency onChange event, which it probably is doing - so I don't understand why SQL Server keeps sending SQLDependency depedencyChanged.
thanks
We are getting the same problem on one database instance, but not on the other. It definitely seems to be some kind of permission problem on the database end, because the exact same NHibernate configuration is used in both cases.
In the working case the cache behaves as expected, in the other (which is a database engine which has much stricter permissions) we get the exact same behaviour you mentioned.