In my init.gradle file, I have defined 2 active recipes.
rewrite {
activeRecipe("org.openrewrite.java.testing.mockito.Mockito1to4Migration", "com.myorg.openrewrite.Mockito1to4Migration")
}
When running gradle -I init.gradle rewriteRun, it seems that the recipe com.myorg.openrewrite.Mockito1to4Migration is run first regardless of the position in the activeRecipe list.
Is the sequence random? How can I force that com.myorg.openrewrite.Mockito1to4Migration is run first.
A change has been push just now that preserves the order of active recipes. This change should end up in release 5.35.0+ of the Gradle plugin; with 5.34.0 released just a couple days ago, I would typically expect the next release in two to three weeks.
Until the next release becomes available, order can be maintained by having a single active recipe, which is a yaml recipe which declares each of the recipes you want to run in order.
Hope that helps!
Related
I get so many frustrations with Azure DevOps. In my Build number format I would like to have both
A number that restart to 0 when I update my major an minor version.
But I also would like to have a real build number that is never reset whatever is my build number format. This build number can also be shared by all my build pipeline of my project. Is it possible?
I'm not using YAML format. I use the classic interfaces with the option page to set my build format. At this moment I have this:
It work except each month the r number restart at 0. I want it to continue.
EDIT
I still didn't decided my final format. I would like to understand all the possibilities. Now I discovered the $(BuildID) property I have another question. Is it possible to have something similar to $(Rev:r) variable but that only check the left part of my build number.
Example:
4.16.$(SequenceFor[4.16]).$(BuildID)
In fact I would like to manually set the Major and Minor version and let the system update one by one the Build and use the Revision for the global $(BuildID).
The $(rev:r) is restarted when the build number changes in any character, so this is the reason why it's restarted whenever the major/minor or the sate changed.
So if you want to use an incremental unique number you can't use the $(rev:r) because then it will be restarted each build.
If you want a number that depends on the major and the minor numbers you need to use the counter expression:
Create 2 variables:
major-minor = 4.16
And a variable that depends on his value and also is a counter:
revision = $[ counter(variables['major-minor'],0) ]
The build number will be:
$(major-minor).$(revision).$(Build.BuildId)
Now, if you will change the major-minor (to 4.17 or 5.16) the revision will be again 0.
I am trying to Get a RD and then call a PUT operation on the release object after updating some Variables in it.
The PUT operation is successful, the variables get updated in the RD, but all the other phases in the environment gets removed, except the 1st phase.
My RD has only one env I have not tried with more than one ENV for this operation.
Please suggest how can I update the RD through Rest call without loosing data.
URLs tried for GET:
The below URL don’t give Deployphases but PUT is successful with deleted phases
https://xxxxxxx.vsrm.visualstudio.com/xxxxxxx/_apis/Release/definitions/2016?api-version=4.1-preview.1
The below URL gives Deployphases but PUT fails with error that Deployphases should not be used rather Deploy step should be used.
https://xxxxxxx.vsrm.visualstudio.com/xxxxxxx/_apis/Release/definitions/2016
URLs tried for PUT:
behavior is same for both the URLs
https://xxxxxxxx.vsrm.visualstudio.com/xxxxxxx/_apis/Release/definitions?api-version=4.1-preview.1
https://xxxxxxxx.vsrm.visualstudio.com/xxxxxxx/_apis/Release/definitions/2016?api-version=4.1-preview.1
It's not a bug, you should use api-version=4.0-preview.3:
https://xxxx.vsrm.visualstudio.com/xxxx/_apis/Release/definitions?api-version=4.0-preview.3
To configure a component I need to add --enable-feature into EXTRA_OECONF_somename
So I tried to do:
EXTRA_OECONF_append_somename = --enable-feature
But it did not help. After investigation it was found that the one of the third-party recipe contains the following line:
EXTRA_OECONF_remove_somename = --enable-feature
I can't modify the third-party recipe.
Is there a way to add --enable-feature into EXTRA_OECONF_somename
Thank you.
I'm afraid not. The _remove operations are always applied last so there is no way to undo them. I would say that the original recipe shouldn't be using it - _remove is intended for distro policy where you want to say "I don't care how this item got in the value, just remove it".
For preference the original recipe should instead it should be using PACKAGECONFIG to control addition (or not) of this feature.
We have two separate builds configured in TeamCity against TFS with the following triggers (listed below).
Build 1:
+:Folder1/Folder2/Folder3/FilePrefix\*\*
+:Source/\*\*
+:Tests/\*\*
Build 2:
+:Folder1/Folder2/\*\*
-:Folder1/Folder2/Folder3/FilePrefix\*\*
-:Tests/\*\*
-:Source/\*\*
If we make a change to a file in Folder1/Folder2/Folder3/FilePrefix we are finding that BOTH builds trigger. The documentation states:
For each file in a change the most specific rule is found (the rule
matching the longest file path). The build is triggered if there is at
least one file with a matching "include" rule or a file with no
matching rules.
Doesn't this mean that only the most specific rule takes precedence? Why isn't Build 2 excluding this file because of the -:Folder1/Folder2/Folder3/FilePrefix**? It seems like the +:Folder1/Folder2/** is overriding the ignore rule.
I ran into this a few weeks ago and found that we had to specify the final wildcard as a '.' instead of a '*' for negation statements.
So your trigger rules for build2 would end up looking like:
+:Folder1/Folder2/\*\.
-:Folder1/Folder2/Folder3/FilePrefix\*\.
-:Tests/\*\.
-:Source/\*\.
The creation date of an executable linked in VS2005 is not set to the real creation-date of the .exe file. Only a complete re-build will set the current date, a re-link will not do it. Obviously the file is set to some date, which is taken from one of the project-files.
So: is there a way to force the linker to set the creation-date to the real link-date?
Delete the executable as part of a pre-link event.
Edit:
Hah, I forgot about Explorer resetting the creation date if you name a file exactly the same as a file that was recently deleted.
Why are you keying off the creation date anyway?
A complete rebuild will delete that file forcing the linker to create it, hence the reason it gets a new creation date. You could try disabling incremental linking under project properties (Linker | General). If that doesn't do it you could add a build event to delete the exe file and force it to create a new file each time. Both of these things could increase your build time.
Deleting the executable doesn't do the job. That's the problem. Also I could not identify any projectfile, whose datetime was the same as the later linked executable. That lets me conclude, that the 'creation date' is an information taken from within some project-file.
The project has 400000 lines, so a full build is no option.
What about using somethign like DirDate (or write a little util yourself) to set the creation date and call it from the post-build step?