I'm using full semver2 version strings which helm supports, here is an example:
'1.2.3-myfeature+11'
The build number is incremented by my CI/CD system every build. In my Chart.yaml and, more importantly, via command line I want to specify a version constraint that always pulls the latest build number. I'm not sure what the right syntax is.
I want to get the latest version of '1.2.3-myfeature'
If I just do this it does not pull the latest build number, I'm not sure how it chooses which version to pull:
helm pull myrepo/mychart --version '1.2.3-myfeature' --devel
If I do this I get a syntax error:
helm pull myrepo/mychart --version '1.2.3-myfeature*' --devel
This also does not work:
helm pull myrepo/mychart --version '~1.2.3-myfeature' --devel
It seems to be using alphanumeric sorting against the entire string after ~1.2.3- when I try to do this?
Related
I am currently Pushing same image twice one with tag number and another with latest tag to artifactory.
For the next release I would like to overwrite the image with latest tag with the new image that contains latest tag. Below is the way I am trying from Azure devops build
Docker Build Command:
$(docker_registry)/$(Build.Repository.Name):$(BuildNbr)
Docker Push Command
$(docker_registry)/$(Build.Repository.Name):$(BuildNbr)
Same above with latest tag, then
docker pull $(docker_registry)/imageName:latest
docker rmi --force $(docker_registry)/imageName:latest //removing latest image from artifactory NOT WORKING
docker pull $(docker_registry)/imageName:$(BuildNbr)
docker tag $(docker_registry)/imageName:$(BuildNbr) $(docker_registry)/imageName:latest
docker push $(docker_registry)/imageName:latest
Somehow the above flow is not working and the latest image is not getting overwritten.
Am I doing any mistake ? I believe rmi command will not delete the image from artifactory.
You can achieve it through the include/exclude pattern for your permissions. You can create a new Permission Target that gives overwrite/delete permissions to tags with "latest" in it:
Remove the include pattern **
Add the include pattern **/latest/*
Add only the required docker repositories (for example "docker local")
Add anyone to this permission target that needs to be able to overwrite/delete.
Then, for all other permission targets, which defines the remainder of the tags (1.1, 1.2, etc), do not provide overwrite/delete permissions. With this, you will be able to overwrite the latest and not other tags.
You can read about include/exclude patterns as they relate to permission targets here.
I want to run bamboo remote agent using docker.
When I run the image atlassian/bamboo-java-agent in my machine it produces the following error
Unable to get Maven version from /usr/share/maven/bin/mvn Could not find system variable
If you wish to use perforce please set the location as a capability.
How to solve these two errors?
I later updated my Maven to higher version 3.3, but that is not reflected when I run the image as shown in the pic attached.
I've got Jenkins set up to do 2 things in 2 separate jobs:
Build an executable jar and push to Ivy repo
Build a docker image, pulling in the jar from the Ivy repo, and push image to a private docker registry
During step 1 the jar will have some version which will be appended to the filename (e.g. my-app-0.1-SNAPSHOT, my-app-1.0-RELEASE, etc.). The problem that I'm facing is that in the Dockerfile we have to pull in the correct jar file based on the version number from the upstream build. Additionally, I would ideally like the docker image to be tagged with that same version number.
Would love to hear from the community about any possible solutions to this problem.
Thanks in advance!!
Obviously you need a unique version from (1) to refer to in (2).
0.1 -> 0.2 -> 0.3 -> ...
Not too complicated in terms of how things work together from a build / Docker point of view. I guess the far bigger challenge is to give up SNAPSHOT builds in the development workflow.
With your current Jenkins: release every build you create a container for.
Much better alternative: Choose a CI / CD server that uses build pipelines. And if you haven't already done so, take a look at the underlaying concept here.
You could use the Groovy Postbulid Plugin to extract with a regular expression the exact name of the generated .jar file at the end of step 1.
Then for step 2, you could have a Dockerfile template and replace in it some placeholder with the exact jar name, build the image and push it to your registry.
Or, if you don't use a Dockerfile you could have in your Docker registry a premade Docker image which has everything but the jar file and add the jar to it with those steps:
create a container from the image
add the jar file into the container using the docker cp command
commit the container into a new image
push the new image to your docker registry
Same need by my customer. We ended up by putting placeholders in the Dockerfile, which are replaced using sed just before the docker build.
This way, you can use the version in multiple locations, either in the FROM or in any filenames.
Example:
FROM custom:#placeholder#
ENV VERSION #placeholder#
RUN wget ***/myjar-${VERSION}.jar && ...
Regarding the consistency, a unique version is used:
from a job parameter (Jenkins)
to build the artifact (Maven)
to tag the Docker image (Docker)
to tag the Git repository containing the Dockerfile (Git)
I'm refactoring/enhancing an Execute Groovy Script build step and am hitting a version compatibility issue between my dev/debugging environment, which is running Groovy 2.3.7, and the version deployed by the groovy-plugin autoinstaller to the slave. We have that set to the relatively stale 2.0.6. The upshot is that I can't use this very handy 2.3+ AST annotation on the Jenkins slave:
file:/C:/Jenkins/workspace/Foo/bar/com/ns1/ns2/MyClass.groovy: 13: unable to resolve class groovy.transform.Sortable
# line 13, column 1.
import groovy.transform.Sortable
^
1 error
What is the path of least resistance to upgrade the slave's Groovy to 2.3.7 or higher? Of note is the autoinstaller only goes up to 2.2.1. (If that's even a viable option here.)
Our Jenkins Groovy plugin is at the latest version, 1.24, and the Jenkins master is at 1.580.1.
Well that was simpler than expected. You can simply kill the http://groovy.codehaus.org installer and point to a fresher repo URL directly by adding a new like so:
Upon job execution the autoinstaller will delete the old Groovy install and unpack the new one. I'm pretty sure it will check timestamps/hashes/something so as not to override the install with the same version on the next run.
According to the docs, a git url can be passed to a build command:
But what happens if the git url needs to be a branch name? In other words, how do I do the equivalent of this:
git clone -b my-firefox-branch
git#github.com:creack/docker-firefox.git
Start your URL with git:// (or https://) and simply append the branch name after #.
I just forked the OP's repo and created a branch to confirm it works (docker version 1.11.1):
root#box:~# docker build git://github.com/michielbdejong/docker-firefox#michielbdejong-patch-1
Sending build context to Docker daemon 52.22 kB
Step 1 : FROM ubuntu:12.04
12.04: Pulling from library/ubuntu
4edf76921243: Downloading
[==========> ] 9.633 MB/44.3 MB
^Croot#box:~#
See https://docs.docker.com/engine/reference/commandline/build/ for full docs.
So far, No. it can't.
Here's what I got:
$ docker build git#github.com:shawnzhu/docker-ruby.git#branch1
2014/12/04 08:19:04 Error trying to use git: exit status 128 (Cloning into '/var/folders/9q/bthxttfj2lq7jtz0b_f938gr0000gn/T/docker-build-git859493111'...
fatal: remote error:
is not a valid repository name
Email support#github.com for help
)
If you take a look at this line of docker CLI code, it only do recursive git clone against given URL of a git repo (even no --depth=1) when using docker build <git-repo-url>.
However, it could be an interesting improvement to docker (if people want it) since #<branch-name> and #<commit> are popular syntax to github URL adopted by lots of tools like npm and bower.
Well it works more or less depending on versions
For recent versions : (docker-engine 1.5.0-0~trusty and+)
docker build https://github.com/rzr/iotjs.git#master
docker build https://github.com/rzr/iotjs.git
docker build github.com/rzr/iotjs.git
For older ones: (docker.io 1.4-5ubuntu1 and -)
docker build https://github.com/rzr/iotjs.git
docker build git://github.com/rzr/iotjs.git
docker build github.com/rzr/iotjs.git
Maybe this can be handled in helper script like:
curl -sL https://rawgit.com/rzr/iotjs/master/run.sh | bash -x -