I have several version with the following version number
2.2.0.0, 2.2.0.1, 2.2.0.2 and 2.2.0
I want to get the 2.2.0 instead of 2.2.0.1.
What i mean is the + just look for the minor version and that digit only without looking forward to the next digit. So that 2.2.+ will only look for 2.2.0,2.2.1,2.2.2..etc...
and won't look for 2.2.0.1, 2.2.0.2...etc.
Is it possible to make the + sign just map like that?
I mean the + sign just look for the third digit and the forth digit will be ignored.
dependencies {
prepare group: "com.abc.efg", name: "app1",version: "2.2.+"
prepare group: "com.abc.efg", name: "app2",version: "2.2.+"
prepare group: "com.abc.efg", name: "app3", version: "2.2.+"
}
Thanks
Related
So, I have a yaml pipeline that has an array storing a set of versions in bash, let's say
arrayVersions=(3.0.1 3.0.2 ....).
Now, I want to set up the pipeline that splits each of these versions in one single job in the yaml pipeline, then run them in multi-agent paradigm.
CONTEXT -
I have set up the pipeline that iterates over the array and runs, however, it is very slow since it runs sequentially. So, I tried multithreaded parallel programming in bash, but it did not work out. In ideal solution, I am thinking to split up all the versions and run them as a new job in the pipeline. It would be something like this:
jobs:
# get all the versions
# split up each version into 1 single job and run the jobs in parallel
job: 3.0.1
...
job: 3.0.2
...
Is there any way I can set it up?
Have you tried using a template and calling it from the jobs section? Here's an example:
# azure-pipelines.yml
trigger:
- none
jobs:
- job: Build
steps:
- template: build-specific-version.yml
parameters:
appVersion:
- '3.0.1'
- '3.0.2'
- '3.0.3'
# build-specific-version.yml
parameters:
- name: 'appVersion'
type: object
default:
- '1.0'
- '1.1'
steps:
- ${{ each v in parameters.appVersion }}:
- script: echo ${{ v }}
Docs: Microsoft technical documentation|Template types & usage
Also see: Loops and arrays in Azure Devops Pipelines
I'm working in a company with a big code base with multiples products,
We use Ansible for our products deployments.
We have multiples shared roles and specific roles per product.
Each shared role is versioning and tagged,
Let's imagine product X in version 1.0.0 and a product Y in version 1.1.0
and 2 shared roles A & B
X has a dependency on role A/B in version 1.0.0
Y has a dependency on role A in version 1.0.0 and role B in version 1.5.0
I'm working on my product X for a new major release 1.1.0
So I'm working too in Ansible to add multiples config files, remove some others, update the shared role A
But my version 1.0.0 is still in production, so it may require some adjustments for bugs. and It may need to update the ansible too.
Now is my problem.
When I release X:1.1.0 with the updated ansible, my playbooks are no more compatible with the 1.0.0 branch.
What's a good practice for handling ansible with a product life
It is good to have a role and tasks per version ?
tasks
- main.yml
- 1.0.0.yml
- 1.1.0.yml
cat main.yml
---
include_tasks: {{product_version}}.yml
include_tasks: 1.1.0.yml
when : product_version >= 1.1.0
and in each version file contains the diff with the previous one ?
but for the 1.10.0, it will become a nightmare...
Do you have any experience for these uses cases ?
First, we must assume that all roles are in their own git repositories. (If they are not, fix that first.) Also, the playbook that will do the installation is also in its own repository, along with a file called roles/requirements.yml. (That is where Ansible Tower expects it to be.)
A particular version of the installation playbook repo will have a particular roles/requirements.yml file which will specify exactly what versions of what roles are needed to run that version of the playbook.
So, for product X, we have a roles/requirements.yml file that says,
- name: A
src: git#gitlab.company.com:mygroup/A.git
scm: git
version: 1.0.0
- name: B
src: git#gitlab.company.com:mygroup/B.git
scm: git
version: 1.0.0
And for product Y, we have a roles/requirements.yml file that says,
- name: A
src: git#gitlab.company.com:mygroup/A.git
scm: git
version: 1.0.0
- name: B
src: git#gitlab.company.com:mygroup/B.git
scm: git
version: 1.5.0
Installing Roles with Ansible Galaxy
I'm setting up an Azure Pipelines build that needs to package a C# .NET class library into a NuGet package.
In this documentation, it lists a couple different ways to automatically generate SemVer strings. In particular, I want to implement this one:
$(Major).$(Minor).$(rev:.r), where Major and Minor are two variables
defined in the build pipeline. This format will automatically
increment the build number and the package version with a new patch
number. It will keep the major and minor versions constant, until you
change them manually in the build pipeline.
But that's all they say about it, no example is provided. A link to learn more takes you to this documentation, where it says this:
For byBuildNumber, the version will be set to the build number, ensure
that your build number is a proper SemVer e.g. 1.0.$(Rev:r). If you
select byBuildNumber, the task will extract a dotted version, 1.2.3.4
and use only that, dropping any label. To use the build number as is,
you should use byEnvVar as described above, and set the environment
variable to BUILD_BUILDNUMBER.
Again, no example is provided. It looks like I want to use versioningScheme: byBuildNumber, but I'm not quite sure how to set the build number, I think it pulls it from the BUILD_BUILDNUMBER environment variable, but I can't find a way to set environment variables, only script variables. Furthermore, am I suppose to just set that to 1.0.$(Rev:r), or to $(Major).$(Minor).$(rev:.r)? I'm afraid that would just interpret it literally.
Googling for the literal string "versioningScheme: byBuildNumber" returns a single result... Does anyone have a working azure-pipelines.yml with this versioning scheme?
Working YAML example for Packaging/Versioning using byBuildNumber
NOTE the second parameter of the counter - it is a seed value, really useful when migrating builds from other build systems like TeamCity; It allows you to set the next build version explicitly upon migration. After the migration and initial build in Azure DevOps, the seed value can be set back to zero or whatever start value (like 100) you may prefer every time majorMinorVersion is changed:
reference: counter expression
name: $(majorMinorVersion).$(semanticVersion) # $(rev:r) # NOTE: rev resets when the default retention period expires
pool:
vmImage: 'vs2017-win2016'
# pipeline variables
variables:
majorMinorVersion: 1.0
# semanticVersion counter is automatically incremented by one in each execution of pipeline
# second parameter is seed value to reset to every time the referenced majorMinorVersion is changed
semanticVersion: $[counter(variables['majorMinorVersion'], 0)]
projectName: 'MyProjectName'
buildConfiguration: 'Release'
# Only run against master
trigger:
- master
# Build
- task: DotNetCoreCLI#2
displayName: Build
inputs:
projects: '**/*.csproj'
arguments: '--configuration $(BuildConfiguration)'
# Package
- task: DotNetCoreCLI#2
displayName: 'NuGet pack'
inputs:
command: 'pack'
configuration: $(BuildConfiguration)
packagesToPack: '**/$(ProjectName)*.csproj'
packDirectory: '$(build.artifactStagingDirectory)'
versioningScheme: byBuildNumber # https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#yaml-snippet
# Publish
- task: DotNetCoreCLI#2
displayName: 'Publish'
inputs:
command: 'push'
nuGetFeedType: 'internal'
packagesToPush: '$(build.artifactStagingDirectory)/$(ProjectName)*.nupkg'
publishVstsFeed: 'MyPackageFeedName'
byBuildNumber uses the build number you define in your YAML with the name field.
Ex: name: $(Build.DefinitionName)-$(date:yyyyMMdd)$(rev:.r)
So if you set your build format to name: 1.0.$(rev:.r), it should work as you expect.
I had the similar issue and now let me make it clear.
Firstly, what is the definition of Build Number?
By the official document of Azure Pipeline YAML scheme, it is
name: string # build numbering format
resources:
containers: [ containerResource ]
repositories: [ repositoryResource ]
variables: { string: string } | [ variable | templateReference ]
trigger: trigger
pr: pr
stages: [ stage | templateReference ]
Look at the first line:
name: string # build numbering format
Yes, that's it!
So you could define it like
name: 1.0.$(Rev:r)
if you prefer to Semantic Versioning. Then
Secondly, what's the meaning of versioningScheme: 'byBuildNumber' in task NuGetCommand#2?
It's really straightforward: just use the format defined by name!
Last but not least
The official document on Package Versioning and Pack NuGet packages don't make it clear that what a build number really is and how to define it. It's really misleading. And I'm so sad as an MS employee as I'd to resort to external resource to make all that clear.
Azure Pipeline Nuget Package Versioning Scheme, How to Get “1.0.$(Rev:r)”
This should be a issue in the documentation. I reproduced this issue when I set $(Major).$(Minor).$(rev:.r) in the Build number format in the Options of build pipeline:
However, I suddenly noticed that the build number is not correct with that format after many build tests:
There are two points . between 0 and 2 (Open above image in a new tab). Obviously this is very strange. So, I changed the Build number format to:
$(Major).$(Minor)$(rev:.r)
Or
$(Major).$(Minor).$(rev:r)
Now, everything is working fine.
As test, I just set the Build number format to $(rev:.r), and the build number is .x. So, we could confirm that the value of $(rev:.r) including the . by default.
Note: Since where Major and Minor are two variables defined in the build pipeline, so we need defined them in the variables manually.
Hope this helps.
Issues
My issues:
when trying the answer by #Emil, my first package started at 2.0 (I did no further testing to investigate)
when trying the answer by #Leo Liu-MSFT, I was unable to find the matching "Options" tab.
I therefore used this solution by #LanceMcCarthy.
Fix
Set the variables:
variables:
major: '1'
minor: '0'
revision: $[counter(variables['minor'], 1)] # This will get reset every time minor gets bumped.
nugetVersion: '$(major).$(minor).$(revision)'
then use nugetVersion as an environment variable when packing:
- task: NuGetCommand#2
inputs:
command: 'pack'
packagesToPack: '**/*.csproj'
packDestination: '$(Build.ArtifactStagingDirectory)'
versionEnvVar: 'nugetVersion'
versioningScheme: 'byEnvVar'
I think the issue many of use have is that there is no option menu. I upvoted SHarpC's post as this worked for me.
I have a workaround to add a suffix (i.e. '-beta'), since it's for some reason ignored by the Nuget pack command when using the Classic editor and setting auto versioning by build number:
Set a new environment variable, set the value as the predefined $(Build.BuildNumber) variable:
Set the build number:
Set NuGet pack command to auto-name by environment variable and specify newly added variable name:
If you're interested in the whole build/release pipeline design and YAML, have a look at my article here
The core of the problem is solved in the approved answer and refined in #Emils answer, so this is just another approach to the azure-pipelines.yml that works for us with DevOps artifacts.
name: $(majorMinorVersion).$(semanticVersion)
trigger:
- main
variables:
majorMinorVersion: 1.0
semanticVersion: $[counter(variables['majorMinorVersion'], 0)]
pool:
vmImage: windows-latest
steps:
- task: DotNetCoreCLI#2
displayName: 'Create Packages'
inputs:
command: pack
configuration: 'Release'
packagesToPack: '**/<VS projectname>.csproj'
versioningScheme: byBuildNumber
- task: NuGetAuthenticate#0
displayName: 'NuGet Authenticate'
- task: NuGetCommand#2
displayName: 'NuGet Push to feed'
inputs:
command: push
publishVstsFeed: '<DevOps projectname>/<feed name>'
BTW: Don't forget this little hinch
I am new to the Google cloud Spanner and to explore it I started with documentation provided by google Here. To explore any database we start with data operations and the same I did, I started with writing data to the spanner using simple java application given here https://github.com/GoogleCloudPlatform/java-docs-samples/blob/master/spanner/cloud-client/src/main/java/com/example/spanner/SpannerSample.java. I have made changes in driver class on respective places shown in following code snippet:
public static void main(String[] args) throws Exception {
String path = "File_Path";
SpannerOptions.Builder options = SpannerOptions.newBuilder().setCredentials(GoogleCredentials.fromStream(new FileInputStream(path)));
options.setProjectId("Project_id");
Spanner spanner = (options.build()).getService();
try {
DatabaseId db = DatabaseId.of("project_id", "spannerInstance", "Database_name");
DatabaseClient dbClient = spanner.getDatabaseClient(db);
run(dbClient);
} finally {
spanner.closeAsync().get();
}
System.out.println("Closed client");
}
Now, When I am trying to execute the code I end up with following error:
Exception in thread "main" java.lang.IllegalArgumentException: Jetty ALPN/NPN has not been properly configured.
at io.grpc.netty.GrpcSslContexts.selectApplicationProtocolConfig(GrpcSslContexts.java:174)
at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:151)
at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:139)
at io.grpc.netty.GrpcSslContexts.forClient(GrpcSslContexts.java:109)
at com.google.cloud.spanner.SpannerOptions$NettyRpcChannelFactory.newSslContext(SpannerOptions.java:283)
at com.google.cloud.spanner.SpannerOptions$NettyRpcChannelFactory.newChannel(SpannerOptions.java:274)
at com.google.cloud.spanner.SpannerOptions.createChannel(SpannerOptions.java:253)
at com.google.cloud.spanner.SpannerOptions.createChannels(SpannerOptions.java:240)
at com.google.cloud.spanner.SpannerOptions.<init>(SpannerOptions.java:89)
at com.google.cloud.spanner.SpannerOptions.<init>(SpannerOptions.java:43)
at com.google.cloud.spanner.SpannerOptions$Builder.build(SpannerOptions.java:180)
while searching for this issue I have been suggest to add some dependencies like:
compile group: 'org.eclipse.jetty.alpn', name: 'alpn-api', version: '1.1.3.v20160715'
compile group: 'org.mortbay.jetty.alpn', name: 'jetty-alpn-agent', version: '2.0.6'
compile group: 'io.grpc', name: 'grpc-all', version: '1.2.0'
compile group: 'io.netty', name: 'netty-all', version: '4.0.29.Final'
compile group: 'org.eclipse.jetty.orbit', name: 'javax.servlet', version: '3.0.0.v201112011016'
but facing same issue, I am also using Bigquery and other GCP's feature one same working environment and they all are working fine except google-Spanner, any suggestion on this is appreciated. Thanks.
Please read the comments on the question, #Mairbek Khadikov and my discussion on this conclude the actual reason of the issue. As discussed in comment the actual problem was with another dependencies.
By adding
configurations {
compile.exclude module: 'netty-all'
}
to the build.gradle file this issue has resolved.
Here is the link of github issue I raised regarding to this error. github issue where I posted exact issue eventually which I got to know and the resolution of that by, '#michaelbausor'.
Ive seen lots of stuff
Foo::VERSION::STRING
Foo::VERSION
Foo::Version
any suggestions what the best/most-common default is ?
First of all, Foo::Version seems wrong to me. That implicates that version is a Class or a Module, but should be a constant, as first two of your examples.
Apart from that, there is no golden rule here. Here are a few examples:
Rails:
Rails::VERSION::STRING
(Note: a module VERSION with all capitals.)
SimpleForm:
SimpleForm::VERSION
Nokogiri:
Nokogiri::VERSION
RSpec:
RSpec::Version::STRING
(Note, a module Version, compare with Rails above.)
Cucumber:
Cucumber::VERSION
SimpleForm:
SimpleForm::VERSION
Most of the above have their version defined in the lib/[name]/version.rb file, except for Rails, which has a version.rb in the root of the project, and Cucumber, which has buried it in the lib/cucumber/platform.rb file.
Also note that all of the above use Strings as a version. (Rails even concatenates MAJOR, MINOR, TINY, and PRE constants into a single VERSION constant.) This allows for easy comparison of versions:
"1.2.3" > "0.4.2" # => true
"1.2.3" > "1.2.2" # => true
"1.2.3" > "1.2" # => true
However, such a comparison fails when you run into double digits for the patch level:
"1.2.3" > "1.2.12" # => true
To me, defining Foo::VERSION is your best bet, define it in lib/foo/version.rb, and make it a String value.