New answers tagged

0

I was able to produce a correct behaviour starting from centos:centos7 base image and installing Docker only (no Jenkins yet) via the steps provided in the official Docker docu: https://docs.docker.com/engine/install/centos/ Seen here: [root@d8d441ae6a7a /]# history 2 yum remove docker docker-client docker-client-...


2

Taking the url from cluster-info and creating a config file with jenkins and using at as secret did the trick to pass the connection. I am still curious how to authenticate with a bearer token though. I have tried to use existing managed Jenkins secret, but it failed with it. Update: The authentication happens, but after creating pods the job never runs. ...


1

Based on your output, all of your docker commands are running as root when in general they should be running as the jenkins user. You can try switching the user to jenkins and running the same docker login and pull commands. I've used the following in my Jenkins pipeline scripts to log into a Nexus 3 Docker repository (https://docs.cloudbees.com/docs/admin-...


5

I guess the simplest and direct solution would be to use GitHub API: https://docs.github.com/en/rest/reference/pulls#create-a-review-for-a-pull-request But for the requirement you have, PR checks is usually the way to go and you have a plugin that does the API communication for you: https://www.jenkins.io/doc/pipeline/steps/pipeline-githubnotify-step/


3

I've done this before, normally in the form of having a /.well-known/info endpoint available on every microservice that then returns a JSON payload with what's in it: { "service_name": "token_exchange", "server_id": "RD1717628373", "commit_hash": "f72a28", "branch": "...


0

You can use the trim parameter: string(name: 'some parameter', trim: true)


1

I assume you talk about jenkins cli? There is no command to abort the safeRestart. Use quiteDown, cancelQuietDown instead and safeRestart only if needed. safeRestart: Puts Jenkins into the quiet mode, wait for existing builds to be completed, and then restart Jenkins quietDown: Put Jenkins in a Quiet mode, in preparation for a restart. In that mode Jenkins ...


1

The answer is in environment variables. All builds should have the "Environment Variables" link, which shows all the environment variables, which you can easily compare. In my case, the difference is in the BUILD_CAUSE and review variables: Build 1 (started by the scheduler): BUILD_CAUSE = SCMTRIGGER Build 2 (started by "build review"): ...


2

I'm not sure if there is a simple way to check if the "scheduler" kicked off the job, but you can check if a user executed the job. In your Jenkins job, check for the presence of the BUILD_USER_ID environment variable. If it is present, retrieve the value and send your email to the specific user(s) (scenario 1). If it is not present, a non-user has ...


2

I believe your issue is the use of * * * * *. The parameterized-scheduler-plugin example has two different times specified. #lets run against the integration environment at 15 past the hour 15 * * * * % env=int #run QA too 30 * * * % env=qa So one job runs @15 and one @30. Yours specify the same time, so only the first is executed. You could try the random ...


2

List workflow runs would be the equivalent API endpoint in Github Actions: GET /repos/:owner/:repo/actions/workflows/:workflow_id/runs You can use the status query parameter e.g. to filter for successful runs: GET /repos/:owner/:repo/actions/workflows/:workflow_id/runs?status=success


-1

Could credentials binding plugin be the answer? The idea is to add svn user and password to Jenkins credentials store and then use it in the pipeline. withCredentials([ usernamePassword( credentialsId: 'mySvnLogin', usernameVariable: 'USER', passwordVariable: 'PASSWORD')]) { sh ''' svn ls <url> --non-interactive --...


0

Setup pipeline name and default version (e.g. master) in "Global Pipeline Libraries" settings. Then use them in your Jenkinsfile as following #!/usr/bin/env groovy @Library('YourGlobalPipelineName@YourDefaultVersion') _ pipeline { }


1

You might try installing the GitHub Integration plugin. Reading their documentation, they provide a number of environment variables you can use for your purpose. GITHUB_PR_STATE can be OPEN, CLOSE GITHUB_PR_SOURCE_BRANCH for the source branch (e.g., hotfix/foo) GITHUB_PR_TARGET_BRANCH or master Using the when condition, you can run a job/stage when it's a ...


Top 50 recent answers are included