I have an Azure DevOps pipeline using a macos-latest image. That constantly fails when the image version is 20201212.1. And it works as expected with the image version 20210110.1.
Is there a way to select the image version in the pipeline?
When using Microsoft-hosted agents to run pipelines, typically it will automatically update the image to the latest release for use (generally updated weekly). And we can't specify the image version of the agents.
Currently the released latest image version of macOS agent (macOS X Catalina 10.15) is 20201212.1 (see here).
The image version 20210110.1 is Pre-release now (see here). Currently, this image version has not been deployed completely on Azure DevOps, and there may be few regions are be able to use this image version.
In your case,
That constantly fails when the image version is 20201212.1. And it works as expected with the image version 20210110.1.
What is the details of the error message in the output logs?
If the issue is caused by different versions of some software installed on the image, you can try to update or install the software with the versions you require. to view more details, you can reference here.
If the issue still exists after changing the software versions, I recommend that you can open an issue on the "actions/virtual-environments" repository for more help.
Related
I just started reading the Jorge Acetozi book "Continuous Delivery for Java Apps: Kubernetes and Jenkins in Practice".
For the code examples I use the source code in his github repository:
https://github.com/jorgeacetozi
Unfortunately this code doesn't work for Java 11 and uses old Spring Boot 1.5 version
Also Jenkins, Selenium, Kubernetes and Vagrant tools, described in the book, use very old versions.
Has anyone finished this book lately, could you please, provide the updated source code for this book?
Unfortunately, the old source code, prevents me from learning further.
I have managed to finish this book, but did a lot of changes to the source code:
https://github.com/skyglass/notepad - updated source code for Notepad Spring Boot application.
Spring Boot has been updated to version 2.4.2.
I had to make lots of changes to the front-end code, to make styles displayed correctly with the latest version of Thymeleaf library.
Also did some other changes, related to update from Java8 to Java11.
All maven dependencies have been updated to the latest versions
https://github.com/skyglass/jenkins-kubernetes-cd - This repository corresponds to Jorge Acetozi's "ebook-continuous-delivery-with-kubernetes-and-jenkins" repository.
"docker-images" folder contain "jenkins", "kubectl" and "maven-jdk11-git" docker image files, which are used by Jenkins pipelines
Kubernetes yaml files have been updated to the latest version of Kubernetes
Unfortunately, I couldn't manage to make acceptance tests working for "Firefox" browser, with the latest "Selenium Grid" docker images. Therefore, acceptance-tests pipeline code only contains tests with "Chrome" browser
All Jenkins files have been updated to use the latest docker images, or custom docker images, published by me in Skyglass Docker Hub. Feel free to publish them in your own docker hub, using docker files from "docker-images" folder.
"docker-images" folder contains custom docker image to run Jenkins. I recommend using this image to run Jenkins on your computer. It uses the latest version of jenkins for jdk11 and all needed plugins with the latest versions
https://github.com/skyglass/notepad-performance-tests - the performance tests have been updated for the latest versions of Scala, SBT and Gatling.
https://tferdinand.net/en/create-a-local-kubernetes-cluster-with-vagrant/
https://www.exxactcorp.com/blog/HPC/building-a-kubernetes-cluster-using-vagrant
These articles will help you to install Kubernetes Cluster locally, with Vagrant and VirtualBox.
Of course, I also used lot of other online resources. StackOverflow helped me a lot. :)
Have fun reading this book, hope these examples help you get the best learning experience.
Thank you, Jorge Acetozi, for this wonderful book!
I just upgraded from SonarQube 6.1 to 6.7.7. For SonarJava, it automatically installed 4.15.0.12310 (it was 4.10.0.10260 before). In the Marketplace, when I hover over the available versions from 5.0-5.13, it says “Incompatible”. When I hover over 5.13.1+, it says “Requires system update”. What does it mean for it to be incompatible if it doesn’t require a system update?
I am seeing this with various other plugins as well, such as SonarPython, which had 1.8 automatically installed. I had to manually install 1.9.1 in order to get this bug fix (which is why I originally upgraded the server): https://community.sonarsource.com/t/python-s1481-code-smell-unused-local-variables-should-be-removed-false-positive-with-string-interpolation/8961
I could manually install newer versions of other plugins as well, but I don’t know if that’s safe.
I also can’t find an official plugin compatibility matrix, since this only shows 7.9+: https://docs.sonarqube.org/latest/instance-administration/plugin-version-matrix/
Incompatible means that the plugin does not work with the version of SonarQube you have installed.
An example of an incompatible plugin would be one where the plugin relied on an API that was removed in your current SonarQube version. You may be able to use that version of the plugin if you downgraded your SonarQube instance to a previous version.
Requires system update means you need to upgrade SonarQube in order to install the plugin.
For what it's worth, the states as described by the API documentation are:
Update status values are:
COMPATIBLE: plugin is compatible with current SonarQube instance.
INCOMPATIBLE: plugin is not compatible with current SonarQube instance.
REQUIRES_SYSTEM_UPGRADE: plugin requires SonarQube to be upgraded before being installed.
DEPS_REQUIRE_SYSTEM_UPGRADE: at least one plugin on which the plugin is dependent requires SonarQube to be upgraded.
How to write a FROM statement in the Dockerfile that pulls the latest image from a specific Major version.
Let's say there is an application that currently has three major versions: v1.7, v2.5, v3.0.5 and I want to have always the latest version of image v2. if i put in the Dockerfile statement:
FROM imagename:latest
Then I'll get build version 3.0.5 because it is the latest version. If I put:
FROM imagename:2.5
Then I'll get exact version 2.5 but will not be able to update the image with this statement once the version 2.6 becomes available.
How to set FROM statement that will get always the latest version 2 updates that will not brake backwards compatibility and stick to that major version 2.?
Docker image tags (including both the Dockerfile FROM line and docker run images) are always exact matches. As a corollary, once Docker believes it has a particular image locally, it won't try to fetch it again unless explicitly instructed to.
Many common Docker images have a convention of publishing the same image under multiple tags, that sort of reflect what you're suggesting. For instance, as of this writing, for the standard python image, python:latest, python:3, python:3.7, python:3.7.0, and python:3.7.0-stretch all point at the same image. If you said FROM python:3 you'd get this image. But, if you already had that image, and a Python 3.8 were released, and you rebuilt without explicitly doing a docker pull first, you'd use the same image you already had (the Python 3.7 one). If you did docker pull python:3 then you'd get the updated image but you'd have to know to do that (or tell your CI tool to do it for you).
I'm trying to achieve the same mechanism as maven provides for SNAPSHOT versions.
Basically, whenever I have a development on a Dockerfile, I want to be able to create temporary versions in my private registry.
I could create a tag and force push on this tag, but I'd rather keep one version in the registry for a given tag.
If Docker image A depends FROM B (on 1.2.SNAPSHOT for instance), then the latest 1.2.x tag will get pulled.
Is there a special keyword in image version that performs what I'm actually trying to achieve ?
Hope this is clear enough :)
I hadn't used them, but it sounds like Maven snapshots are used to indicate a development version. As a result new versions are always checked for and fetched.
To get similar behavior in docker, I believe you'd need to check for a newer base image on each build. That's an option in docker build: --pull
docker build --pull -t myimage .
I ran into an issue today where my preview server was running an older version of a project instead of the most recently published version. The most recently published version was 1.0.4.10, but after some testing, I determined that version was not the version of the application that the server was retrieving.
After trying a few things, I tried publishing a new version under 1.0.5.0 instead of continuing with the 1.0.4.xx numbering, and that fixed the issue.
VS's auto increment feature recommended 1.0.4.10, but is there an issue with this being the same as 1.0.4.1? So maybe it was running 1.0.4.9? Or something behind the scenes I'm not aware of?