I use matrix.include to trigger multiple test among diffrent os,the config is as follows:
matrix:
include:
- name: "build on linux"
os: linux
dist: trusty
sudo: required
services: docker
- name: "build on mac"
os: osx
osx_image: xcode10
env: CPPFLAGS=-I/usr/local/opt/openssl/include LDFLAGS=-L/usr/local/opt/openssl/lib
- name: "build on windows"
os: windows
I expected all the OS would run the build, but only the first triggered, the others was ignored for some reason.
The link of the config of the travis-ci is here.
I've found that travis's jobs key tends to override matrix:includes.
Have you tried removing the jobs system to see if the matrix works?
Related
CircleCI Install Serverless CLC build suddenly fails, Have not changed anything in config file.
version: 2.1
orbs:
aws-cli: circleci/aws-cli#3.1
build-tools: circleci/build-tools#3.0.0
node: circleci/node#5.0.3
python: circleci/python#2.1.1
docker: circleci/docker#2.2.0
serverless-framework: circleci/serverless-framework#2.0.0
- serverless-framework/setup
- node/install-packages
- setup_remote_docker
I was able to fix it by updating the serverless-framework version to serverless-framework: circleci/serverless-framework#2.0.1
When I have a travis matrix build with a spec like this:
matrix:
include:
- os: osx
rust: stable
- os: linux
rust: stable
allow_failures:
- os: osx
and I use the deploy provider to upload an html book generated during the build:
deploy:
provider: pages
skip-cleanup: true
github-token: $GITHUB_PAGES_TOKEN
local-dir: target/html
keep-history: false
on:
branch: master
Which build output is that gh_pages provider running on?
From experimentation, it seems that the deploy: gh_pages provided is run on the last build in my matrix, in the example above: linux.
I am unsure if failure_allowed on the other builds (possibly combined with fast_fail) could change that though.
i.e.If the last one is allowed to fail (and it does) then I think the deployer will not run, even if overall the build has "succeeded" and is green.
I am using the latest HELM stable/jenkins charts installed on my single node cluster for testing.
Install NFS provisioner.
helm repo add stable https://kubernetes-charts.storage.googleapis.com
helm install nfs-client-provisioner stable/nfs-client-provisioner --version 1.2.8 --set nfs.server=*** --set nfs.path=/k8snfs --set storageClass.name=nfs --wait
Install stable/jenkins. Only custom values were serviceType and storageClass.
helm install jenkins stable/jenkins -f newJenkins.values -n jenkins
The newJenkins.values has the following.
master:
adminPassword: admin
serviceType: NodePort
initContainerEnv:
- name: http_proxy
value: "http://***:80"
- name: https_proxy
value: "http://***:80"
- name: no_proxy
value: "***"
containerEnv:
- name: http_proxy
value: "http://***:80"
- name: https_proxy
value: "http://***:80"
- name: no_proxy
value: "***"
javaOpts: >-
-Dhttp.proxyHost=***
-Dhttp.proxyPort=80
-Dhttps.proxyHost=***
-Dhttps.proxyPort=80
persistence:
storageClass: nfs
Login to Jenkins and Create Jenkins credential of "Kubernetes Service Account".
Under "Configure Clouds", I leave all defaults and press "Test Connection". Test fails.
In the credentials dropdown, I chose 'secret-text' and pressed button again. Still fail.
The error reported was.
Error testing connection https://kubernetes.default: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
When I check in the pod logs, the only error I see it the following.
2020-05-06 01:35:13.173+0000 [id=19] INFO o.c.j.p.k.KubernetesClientProvider$SaveableListenerImpl#onChange: Invalidating Kubernetes client: kubernetes null
I've been googling for a while and many sites mention service account settings, but nothing works.
$ kubectl version --short
Client Version: v1.12.7+1.2.3.el7
Server Version: v1.12.7+1.2.3.el7
$ helm version --short
v3.1.0+gb29d20b
Is there another step?
That error is a common error message reported by the Java Virtual Machine. This is caused when the Java environment does not have information about the HTTPS server to verify that it is a valid website. Sometimes the certificate is provided by an internal Root CA or is a Self-Signed Certificate. This sometimes can confuse the JVM as it is not one of the ones on the Java “trusted” list who can provide these certificates.
Try to add your Java Options in values.yaml file should look like this:
javaOpts: >-
-Dhttp.proxyHost=***
-Dhttp.proxyPort=80
-Dhttps.proxyHost=***
-Dhttps.proxyPort=80
-Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacert
-Djavax.net.ssl.trustStorePassword=changeit
EDIT:
Try to change location of authority file, add debug option (-Djavax.net.debug=ssl) for seeing more detail view of logs. Normally without that parameter we wont be able to see more details log:
javaOpts: >-
-Dhttp.proxyHost=***
-Dhttp.proxyPort=80
-Dhttps.proxyHost=***
-Dhttps.proxyPort=80
-Djavax.net.ssl.trustStore=$JAVA_HOME/lib/security/cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.debug=ssl
If security is not a core concern in this box, you may in Jenkins web UI go to Manage Jenkins > Manage Plugins > tab Available and search for "skip-certificate-check" plugin.
On installing this, the issue should be fixed. Use this plugin with caution, since it is not advised from security perspective.
Also the repo stable is going to be deprecated very soon and is not being updated. I suggest use jenkins chart from Helm Hub.
Please take a look: certification-path-jenkins, adding-ca-cert, adding-path-certs.
A colleague of mine removed mysqli driver in one of our Dockerfile for PHP hosting and it causes problem. Luckily it is discovered in staging environment.
Is there any tools our there that does unit testing for docker images and if there are certain unavailability of an essential driver, fail it in the CI/CD pipeline?
Download the latest shaded dist from https://github.com/dgroup/docker-unittests/releases:
wget https://github.com/dgroup/docker-unittests/releases/download/s1.1.1/docker-unittests-app-1.1.1.jar
De fine an *.yml file with tests.
version: 1.1
setup:
- apt-get update
- apt-get install -y tree
tests:
- assume: java version is 1.9, Debian build
cmd: java -version
output:
contains:
- openjdk version "9.0.1"
- build 9.0.1+11-Debian
- assume: curl version is 7.xxx
cmd: curl --version
output:
startsWith: curl 7.
matches:
- "^curl\\s7.*\\n.*\\nProtocols.+ftps.+https.+telnet.*\\n.*\\n$"
contains:
- AsynchDNS IDN IPv6 Largefile GSS-API
- assume: Setup section installed `tree`
cmd: tree --version
output:
contains: ["Steve Baker", "Florian Sesser"]
Run tests for image
java -jar docker-unittests.jar -f image-tests.yml -i openjdk:9.0.1-11
https://i.stack.imgur.com/DSv72.png
More you can find in https://github.com/dgroup/docker-unittests.
Feel free to submit new issues/questions/etc.
Did you know about Google's tool for testing container images - container-structure-test?
This utility can be easily integrated in CI/CD pipeline as artifact check step.
It seems that travis provisions a 64bit build machine by default when a integration process starts.
Is there any options that I can use in .travis.yml to request a 32bit Ubuntu build machine?
I really need 32bit OS, because the 64Bit Ubuntu refuse to install 32bit supporting libraries (ia32-libs).
The following packages have unmet dependencies:
ia32-libs : Depends: ia32-libs-multiarch
E: Unable to correct problems, you have held broken packages.
No, there is no such option (at least for now). See this issue: #986 travis_ci: Add 32-bit environments
#roidrage commented on 23 Jul 2015:
Closing this issue for now, as we have no immediate plans to add this feature.
Should we add it to the roadmap eventually, we'll make sure to update this ticket.
Travis supports a number of architectures using the arch: key. Unfortunately, none of these are 32-bit.
'shoogle' at https://github.com/travis-ci/travis-ci/issues/5770 suggests that it is possible to run a 32-bit image within a 64-bit container, by adding the following to .travis.yml:
services:
- docker
script:
- "docker run -i -v \"${PWD}:/MyProgram\" toopher/centos-i386:centos6 /bin/bash -c \"linux32 --32bit i386 /MyProgram/build.sh\""
And dlang suggest:
env:
- ARCH="x86_64"
matrix:
include:
- {os: linux, d: dmd-2.071.0, env: ARCH="x86", addons: {apt: {packages: [[gcc-multilib]]}}}
- {os: linux, d: ldc-1.0.0, env: ARCH="x86", addons: {apt: {packages: [[gcc-multilib]]}}}
script:
- dub test --arch "$ARCH"