Is there a way to provide a "display name" for steps that would be shown in the build details of the build history?
What is currently display is the "name" field which is used to indicate the container image and is not a very useful way to convey meaning.
The id field worked for me. I have a cloudbuild.yaml file as below:
steps:
- id: 'build-container-image'
name: 'gcr.io/cloud-builders/docker'
args:
- 'build'
- '--network=cloudbuild'
- '-t'
- '${_REGION_NAME}-docker.pkg.dev/$PROJECT_ID/${_REPO_NAME}/${_SERVICE_NAME}'
- '.'
- id: 'push-image-to-artifact-registry'
name: 'gcr.io/cloud-builders/docker'
args:
- 'push'
- '${_REGION_NAME}-docker.pkg.dev/$PROJECT_ID/${_REPO_NAME}/${_SERVICE_NAME}'
- id: 'deploy-image-to-cloud-run'
name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
entrypoint: gcloud
args:
- 'run'
- 'deploy'
- '${_SERVICE_NAME}'
- '--image'
- '${_REGION_NAME}-docker.pkg.dev/$PROJECT_ID/${_REPO_NAME}/${_SERVICE_NAME}'
- '--region'
- '${_REGION_NAME}'
- '--platform'
- 'managed'
- '--allow-unauthenticated'
substitutions:
_REGION_NAME: us-west1
_REPO_NAME: container-images
_SERVICE_NAME: public-web-cloud-run
images:
- '${_REGION_NAME}-docker.pkg.dev/$PROJECT_ID/${_REPO_NAME}/${_SERVICE_NAME}'
This is what will be shown in the build details without the id field
This is the build details after the id fields are added:
Link to the id field in the official doc
Found out after some tests that the "id" field is presented 'as is' in the build details for each step and can be used as a field that is presented in the console. Note though that substitutions (i.e. ${QQQ}) did not work for me in the 'id' field
Related
I am learning how to create azure pipeline and ran into the following error:
The pipeline is not valid. Job Phase_1: Step
AzureResourceGroupDeployment input ConnectedServiceName expects a
service connection of type AzureRM but the provided service connection
"MY-SERVICE-CONNECTION-NAME" is of type generic.
What am I missing here?
azure-pipelines.yml
# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml
trigger:
branches:
include:
- master
paths:
include:
- cosmos
batch: True
jobs:
- job: Phase_1
displayName: Phase 1
cancelTimeoutInMinutes: 1
pool:
vmImage: ubuntu-latest
steps:
- checkout: self
- task: AzureResourceGroupDeployment#2
displayName: Azure Deployment:Create Or Update Resource Group action on DISPLAY-NAME
inputs:
# azureSubscription: 'SUBSCRIPTION'
ConnectedServiceName: MY-SERVICE-CONNECTION-NAME
resourceGroupName: DISPLAY-NAME
location: West US # TBD
csmFile: cosmos/deploy.json
csmParametersFile: cosmos/parameters-dev.json
deploymentName: DEPLOYMENT-NAME
I tried values from "service connections" but not sure what is the issue here.
The error message is telling you the exact problem. Your service connection needs to be an Azure Resource Manager service connection. Create a service connection of the appropriate type.
I can reproduce the issue:
As Daniel said, this is caused by the service connection type.
From this document you can know what the parameters are:
https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/AzureResourceGroupDeploymentV2/README.md#parameters-of-the-task
Share a little trick. Can help you avoid this type of problem in the future. When you type '- task: sometask#version' in the correct place of YML file of the pipeline in DevOps, you will see a 'Settings' button in the upper left, click it and you can set the value through the UI, which can filter the appropriate options for you:
I already set up custom machine types in the cloud build file.
But, google tall me a warning (Long build duration).
Custom machine types not applied!
What did I do wrong?
cloudbuild.yaml
steps:
- name: "gcr.io/cos-cloud/cos-customizer"
args:
[
"start-image-build",
"-image-project=cos-cloud",
"-image-name=${_BASE_IMAGE_NAME}",
"-gcs-bucket=${_CLOUD_BUILD_BUCKET_NAME}",
"-gcs-workdir=cloud-build-${BUILD_ID}",
]
- name: "gcr.io/cos-cloud/cos-customizer"
args:
[
"run-script",
"-env=_MIX_ENV=${_MIX_ENV},_RELEASE_NAME=${_RELEASE_NAME}",
"-script=cloudbuild.sh",
]
- name: "gcr.io/cos-cloud/cos-customizer"
args:
[
"finish-image-build",
"-zone=us-central1-a",
"-project=${PROJECT_ID}",
"-image-project=${PROJECT_ID}",
"-image-family=${_IMAGE_FAMILY_NAME}",
"-image-name=${_BASE_IMAGE_NAME}-${_IMAGE_FAMILY_NAME}-${SHORT_SHA}",
]
options:
machineType: "E2_HIGHCPU_8"
timeout: 3600s
Google's build duration warning
This is not a CloudBuild problem.
cos-customizer configures the machine type is impossible.
https://github.com/GoogleCloudPlatform/cos-customizer/issues/79
I have a pipeline in Azure DevOps which build my iOS application I want to separate the environments and what I am building for by jobs and conditions. I have set up the initial parameter select:
parameters:
- name: Environment
displayName: "Environment"
type: string
default: Dev
values:
- Dev
- Live
- name: Build
displayName: "Build"
type: string
default: iPhone
values:
- iPhone
- iPhoneSimulator
and then where I set up the different job I have added a condition:
- job:
condition: and(succeeded(), eq(${{ parameters.Build }}, iPhone))
steps:
- checkout: none
When I try to run this I get the following error:
An error occurred while loading the YAML build pipeline. Unrecognized value: 'iPhone'. Located at position 21 within expression: and(succeeded(), eq(iPhone, iPhone)).
iPhone is not a valid literal. Since parameter expansion happens before condition evaluation, you need to make sure that your condition has proper syntax after parameter expansion by enclosing string literals in single quotes:
and(succeeded(), eq('${{ parameters.Build }}', 'iPhone'))
Can you please help on my below issue.
As i am doing sonar scanner using cloud build with an advantage of secret manger but facing issue.
And followed same steps of https://cloud.google.com/cloud-build/docs/securing-builds/use-secrets
here is my code
steps:
- name: 'gcr.io/$_PROJECT_ID/sonar-scanner:latest'
entrypoint: 'bash'
args:
- '-c'
- '-Dsonar.host.url=http://sonar:9000/'
- '-Dsonar.login=$$USERNAME'
- '-Dsonar.password=$$PASSWORD'
- '-Dsonar.projectKey=$_BRANCH-analytics'
- '-Dsonar.sources=.'
secretEnv: ['USERNAME', 'PASSWORD']
dir: 'analytics'
availableSecrets:
secretManager:
- versionName: projects/project-id/secrets/sonar_pass/versions/1
env: 'PASSWORD'
- versionName: projects/project-id/secrets/sonar_user/versions/2
env: 'USERNAME'
tags: ['cloud-builders-community']
and the issue i am facing is:
bash: line 0: bash: -Dsonar.login=$USERNAME: invalid option name
ERROR
ERROR: build step 0 "gcr.io/project-id/sonar-scanner:latest" failed: step exited with non-zero status: 2
tried with different items but can't find a solution.
I am grateful if you guys help me on this.
Thank you
I actually had the same problem as you. It is indeed quite important that you use entrypoint: 'bash' and '-c', otherwise Cloud Build doesn't recognise the variables from the secret manager.
My cloudbuild.yaml step looks like this:
steps:
id: 'sonarQube'
name: 'gcr.io/$PROJECT_ID/sonar-scanner:latest'
entrypoint: 'bash'
args:
- '-c'
- |
sonar-scanner -Dsonar.host.url=<url> -Dsonar.login=$$SONARQUBE_TOKEN -Dsonar.projectKey=<project-key> -Dsonar.sources=.
secretEnv: ['SONARQUBE_TOKEN']
availableSecrets:
secretManager:
- versionName: projects/<project-id>/secrets/sonarqube-token/versions/latest
env: 'SONARQUBE_TOKEN'
I had some problems with the latest sonar-scanner image, because it used alpine. I got the next error: jre-bin-java-not-found even though the image has Java. Based on this, I created thus my own Docker image based on Ubuntu instead of Alpine. You can find the image in a pull request.
I found this example of using sonar-scanner in Cloud Build. It seems that sonar-scanner should be used without bash
I think that you should remove entrypoint: 'bash' and '-c'.
The similar approach is in this SO question. It should solve this error.
I'm currently attempting to use the commands feature available in CircleCI version 2.1, so that I can reuse some common commands. I'm testing using the CLI command:
circleci config process ./.circleci/config.latest.yaml > ./.circleci/config.yml
But I recieve the following error:
Error: Error calling workflow: 'main'
Error calling job: 'build'
Error calling command: 'build_source'
Cannot find a definition for command named restore-cache
It seems that restore-cache works just fine in a straight-up version 2 config file, but when I try and process a 2.1 file using process it kicks up a fuss.
Below is an edited version of my config.yaml file which should hopefully be of some use. Please let me know if there is any additional information that would be useful.
version: 2.1
defaults: &defaults
/**
* Unimportant stuff
*/
aliases:
- &restore-root-cache
keys:
- v1-deps-{{ .Branch }}-{{ checksum "package.json" }}
- v1-deps-{{ .Branch }}
- v1-deps
commands:
build_source:
description: 'Installs dependencies, then builds src, builds documentation, and runs tests'
steps:
- restore-cache: *restore-root-cache
- other-commands...
jobs:
build:
<<: *defaults
steps:
- checkout
- build_source
workflows:
version: 2.1
main:
jobs:
- build:
filters:
branches:
ignore: develop
The command is restore_cache (with an underscore), not restore-cache (with a dash) https://circleci.com/docs/2.0/configuration-reference/#restore_cache
It should work in commands.
restore cache is a special step that needs to be under a job. Not another command.