I installed new node_exporter.
Mertics aviable on
server01:9100/metrics
for example
...
node_filesystem_device_error{device="/dev/sda1",fstype="ext4",mountpoint="/boot"} 0
node_filesystem_device_error{device="/dev/sdb1",fstype="xfs",mountpoint="/data"} 0
wrote in config prometheus.yml new job and target
- job_name: node_exporter_metrics
metrics_path: /metrics
static_configs:
- targets: ['server01:9100']
After restarted Prometheus.
Checked avialability new job and target by API, returned:
{"discoveredLabels":{"__address__":"server01:9100","__metrics_path__":"/metrics","__scheme__":"http","job":"node_exporter_metrics"},"labels":{"instance":"server01:9100","job":"node_exporter_metrics"},"scrapeUrl":"http://server01:9100/metrics","lastError":"","lastScrape":"2017-12-14T17:32:02.835779115+03:00","health":"up"}
tried to get values by new job
http://server01:9090/api/v1/query_range?query=node_exporter_metrics&start=1513255115&end=1513258715&step=60
result
{"status":"success","data":{"resultType":"matrix","result":[]}}
How solve this problem?
http://server01:9090/api/v1/query_range?query=node_exporter_metrics&start=1513255115&end=1513258715&step=60
The name of the metric is not node_exporter_metrics, it's node_filesystem_device_error. node_exporter_metrics is the job label.
Related
I have followed the guide described in Conditional steps in jobs and conditional workflows and written the below code for my CircleCI pipeline.
version: 2.1
workflows:
version: 2.1
workflowone:
when:
condition: false
jobs:
- samplejob:
workflowtwo:
when:
condition: true
jobs:
- jobone
jobs:
samplejob:
docker:
- image: buildpack-deps:stable
steps:
- run:
name: Sample Job in WF 1
command: |
echo "This job is in workflowone and the workflow should not run"
jobone:
docker:
- image: buildpack-deps:stable
steps:
- run:
name: Sample Job in WF 2
command: |
echo "This job is in workflowtwo and the workflow should run"
When I run the above code the output is not what is expected. First workflow should not run because the condition is false. Both worflows start running when the pipeline in triggered. Can anyone point out the missing piece here?
According to the CircleCI docs, workflows (specifically) does not accept the condition key:
Note: When using logic statements at the workflow level, do not
include the condition: key (the condition key is only needed for job
level logic statements).
See here logic-statement-examples (scroll to the bottom of this section to see the note)
Recently I've made some configuration on my team's github circleci. I needed to use a when statement to devide ci logics. I referenced this document(https://circleci.com/docs/2.0/configuration-reference/#logic-statements) but it seems the document not correct.
Below is my step definition:
...
image_build_step:
executor: golang_executor
steps:
- checkout
- setup_remote_docker:
version: 18.09.3
docker_layer_caching: true
- define_svc_name:
jobname: ${CIRCLE_JOB} # On this step set $SVC variable
- when:
conditon:
equal: ["${SVC}", "SVC_A" ]
- aws-ecr/build-and-push-image:
repo: SVC_A_REPO
dockerfile: ./Dockerfile
tag: "latest,${CIRCLE_SHA1},build-${CIRCLE_BUILD_NUM}"
...
Also I already tried this.
...
image_build_step:
executor: golang_executor
steps:
- checkout
- setup_remote_docker:
version: 18.09.3
docker_layer_caching: true
- define_svc_name:
jobname: ${CIRCLE_JOB} # On this step set $SVC variable
- when:
equal: ["${SVC}", "SVC_A" ]
- aws-ecr/build-and-push-image:
repo: SVC_A_REPO
dockerfile: ./Dockerfile
tag: "latest,${CIRCLE_SHA1},build-${CIRCLE_BUILD_NUM}"
...
I cannot figure out my mistake using when statement on circleci. Additionaly, I already passed circleci config validate .circleci/config.yaml command before I pushed this commit.
What is the correct usage of when statement in circleci? Joining circleci forum is also annoying me using github account, so I leave my question on stakeoverflow.
It's not possible to use environment variables in logic statements. The reason is that logic statements are evaluated at configuration compilation time, whereas environment variables are interpolated at run time.
The only workaround I know of is to use the CircleCI dynamic configuration functionality to set pipeline parameters' values in the "setup workflow" that you then pass to the "continuation" workflow.
I am trying to run sonarcloud-quality-gate check after performing sonarcloud-scan. I am doing this because I want bitbucket build pipeline should fail if the quality gate check is failed.
Doing this I get some error like this
Quality Gate failed: Could not get scanner report: [Errno 2] No such file or directory: '/opt/atlassian/pipelines/agent/build/.bitbucket/pipelines/generated/pipeline/pipes/sonarsource/sonarcloud-scan/sonarcloud-scan.log'
This is how my bitbucket.yml looks.
image: node:10.15.3
clone:
depth: full # SonarCloud scanner needs the full history to assign issues properly
definitions:
caches:
sonar: ~/.sonar/cache # Caching SonarCloud artifacts will speed up your build
steps:
- step: &build-test-sonarcloud
name: Build, test and analyze on SonarCloud
caches:
- node
- sonar
script:
- npm install --quiet
- npm run test:coverage
- pipe: sonarsource/sonarcloud-scan:0.1.5
variables:
SONAR_TOKEN: ${SONAR_TOKEN}
EXTRA_ARGS: '-Dsonar.sources=src -Dsonar.tests=src -Dsonar.test.inclusions="**.test.jsx" -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info'
- pipe: sonarsource/sonarcloud-quality-gate:0.1.1
variables:
SONAR_TOKEN: ${SONAR_TOKEN}
pipelines:
default:
- step: *build-test-sonarcloud
Although solarcloud-scan pipe runs successfully.
The problem is that the sonarsource/sonarcloud-quality-gate pipe requires a newer version of the sonarsource/sonarcloud-scan pipe. (This was the case ever since the first release of the sonarsource/sonarcloud-quality-gate pipe.)
Change your pipeline configuration like this:
- pipe: sonarsource/sonarcloud-scan:1.0.1
variables:
SONAR_TOKEN: ${SONAR_TOKEN}
EXTRA_ARGS: '-Dsonar.sources=src -Dsonar.tests=src -Dsonar.test.inclusions="**.test.jsx" -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info'
- pipe: sonarsource/sonarcloud-quality-gate:0.1.3
variables:
SONAR_TOKEN: ${SONAR_TOKEN}
An easy way to see the latest versions is in the pipeline editor.
When you edit the bitbucket-pipelines.yml file, a sidebar like this opens,
where you can filter the list by entering "sonar":
And then, click on a pipe to see details, and note the version used.
I'm new to bamboo and webhooks. I'm trying to start a bamboo build automatically when a PR to master branch from my repo is opened.
I followed this guide but the remote trigger is not starting at all.
Bamboo:
BitBucket:
I've already checked the following:
verify that the whitelisted ip is correct (the bitbucket webhook fails if i remove that)
my bamboo plan is enabled and is building fine on manual run
What am I missing?
Bamboo build plan in YAML:
---
oid: 7818389690603565060
key: XT
name: XXX - TEMP
project:
oid: 7819374853022025730
key: DIGQA
repositories:
- oid: 7818811903068661169
parentRepository: 7818811903068661168
triggers:
- name: Bitbucket Server repository triggered
description: ''
pluginKey: com.atlassian.bamboo.plugins.stash.atlassian-bamboo-plugin-stash:stashTrigger
enabled: true
configuration: {}
triggerConditions:
com.atlassian.bamboo.triggercondition.internal:plansGreenCondition:
enabled: 'false'
triggeringRepositories:
- 7818811903068661169
- name: Remote trigger
description: Master PR Trigger
pluginKey: com.atlassian.bamboo.triggers.atlassian-bamboo-triggers:remote
enabled: true
configuration:
repository.change.trigger.triggerIpAddress: 10.40.1.120
triggerConditions:
com.atlassian.bamboo.triggercondition.internal:plansGreenCondition:
enabled: 'false'
triggeringRepositories:
- 7818811903068661169
branchConfiguration:
planBranchCreation:
enabled: false
removedBranchCleanup:
enabled: false
inactiveBranchesCleanup:
enabled: false
merging:
enabled: false
notificationStrategy: notifyCommitters
triggers: inherited
issueLinking: enabled
dependencies:
configuration:
enabledForBranches: 'true'
requireAllStagesPassing: null
blockingStrategy: none
childPlans: []
permissions:
users:
xxxxxxxx:
- administration
- build
- clone
- read
- write
groups: {}
roles:
user:
- read
anonymous:
- read
plugins:
- pluginKey: com.atlassian.bamboo.plugin.system.additionalBuildConfiguration:concurrentBuild
configuration:
custom.concurrentBuilds.overrideNumberOfConcurrentBuilds: 'true'
custom.concurrentBuilds.numberOfConcurrentBuilds: '1'
- pluginKey: com.atlassian.bamboo.plugin.system.additionalBuildConfiguration:buildExpiry
configuration:
custom.buildExpiryConfig.enabled: 'false'
- pluginKey: com.atlassian.bamboo.plugin.artifact.handler.local:artifactHandlersConfiguration
configuration:
custom.artifactHandlers.useCustomArtifactHandlers: 'false'
buildDefinition:
custom.predefinedVariables: '{"variableSetList":[]}'
stages:
- oid: 7818530428091950756
name: Default Stage
jobs:
- oid: 7818671165580276746
key: JOB1
name: Default Job
tasks:
- oid: 7819234115533708305
description: Checkout Default Repository
pluginKey: com.atlassian.bamboo.plugins.vcs:task.vcs.checkout
configuration:
repositories:
- ref: defaultRepository
buildDefinition:
cleanWorkingDirectory: false
repositoryDefiningWorkingDirectory: -1
...
===========================================================================
EDIT 1:
Okay, so I realized the hook and the trigger is actually working. I misunderstood the trigger setup on bamboo.
Current behavior:
PR to master is opened
BitBucket webhook (on PR) is fired
Bamboo trigger is set to remote / bitbucket server repo. Because of this, the build will not start until the changes are commited / PR is actually merged
Problem:
I want the build to trigger once the PR is opened (before merge). To a bit more context, this is the ideal flow of my build:
Checkout the PR code (revision)
Run my tests against the PR revision
I'm looking at the following links as it seems they managed to do it somehow but I can't make sense of the bits of info provided in both the links.
bamboo - build my pull request
What's wrong with bamboo
Since you are using Bamboo and Bitbucket Server (not Cloud), follow the instructions here:
https://confluence.atlassian.com/bamboo/integrating-bamboo-with-bitbucket-server-779302772.html
You need to create an application link between Bamboo and BBS - application links are between Atlassian applications.
Found out that this feature is supported out of the box as of Bamboo 6+: Reference
I am using jenkins-job-builder to create my pipeline project. But I have a problem with the variables values when I am trying to reuse or propagating.
It is my project configuration:
- project:
name: myproject
git_url: git#gitlabserver.cu:demos-products/myproject.git
jobs:
- '{name}-nfr-smoke-tests':
pipeline-next: '{name}-nfr-smoke-tests'
And here is my job-template:
- job-template:
name: "{name}-nfr-smoke-tests"
node: 'slave1'
scm:
- git:
skip-tag: false
url: 'git#gitlabserver.cu:test-products/{name}-nfr-tests.git'
branches:
- master
wipe-workspace: true
builders:
- shell: |
bundle install
bundle exec cucumber features/smoke.feature
publishers:
- trigger:
project: "{pipeline-next}"
threshold: SUCCESS
Ok, now when I run this configuration in jenkins and I check the job's construction, it says:
No such project ‘{name}-nfr-smoke-tests’. Did you mean ‘myproject-nfr-smoke-tests’?
Why the line: pipeline-next: '{name}-nfr-smoke-tests'doesn't propagates the value of variable name and just used it as a literal string? I am missing something.
You are missing 'name' under 'project' section in your job-template. Append the following lines:
- project:
name: project-name
The purpose of a project is to collect related jobs together, and provide values for the variables in a Job Template.
I found out that Jenkins Job Builder version 0.9.0-0.2 does not propagate the value, but for me version 1.3.0+2015.12.15.git136.959eb4b909-1 did. Perhaps updating your version of Jenkins Job Builder might help?