checkmarx plugin installation
>From the update center, it is possible to install checkmarx plugin, the plugin version available is 8.90.4. However, checkmarx releases page (https://github.com/jenkinsci/checkmarx-plugin/releases) shows many versions later than 8.90.4; however, there is no hpi files to download. Has anything changed with the integration of checkmarx in Jenkins? /Ram -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/21b488c0-7de8-419d-bdd4-2cd692c16277o%40googlegroups.com.
Re: SSH Agent, z/OS USS, and git authentication problems
If the operation you're performing is a checkout, why use the ssh-agent
wrapper? Why not use the same credentials ID as an argument to checkout
rather than wrapping checkout in ssh-agent?
On Mon, Jul 13, 2020 at 8:45 AM Randall Becker
wrote:
> I wish it was that simple. The issue definitely appears to be the encoding
> of the private key during a key exchange. When using SSH-Agent and git
> commands from within a shell in the pipeline, the authentication works
> fine. So this is likely an interaction with the GitSCM plugin not being
> aware of IBM-1047 encodings.
>
> On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote:
>>
>> I think that this is the reason why it does not work
>> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-
>>
>> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker escribió:
>>>
>>> I'm having issues trying to get an agent to authenticate using the SSH
>>> Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins controller. The
>>> goal is to convince GitSCM to actually fetch properly. We get SSH
>>> authentication errors no matter what happens. This is using Pipelines.
>>>
>>> I've tried
>>> sshagent (credentials: ['mvs-randall']) {
>>> checkout([$class: 'GitSCM',
>>> branches: [[name: '*/development']],
>>> extensions: [
>>> [$class: 'CleanBeforeCheckout'],
>>> [$class: 'SubmoduleOption',
>>> disableSubmodules: false, parentCredentials: true,
>>> recursiveSubmodules: true,
>>> reference: '', trackingSubmodules: false]],
>>> doGenerateSubmoduleConfigurations:
>>> false, submoduleCfg: [],
>>> userRemoteConfigs: [[url:
>>> 'g...@xx.xxx.xxx.xxx:proj/repo.git'']]])
>>> }
>>> and
>>> checkout([$class: 'GitSCM',
>>> branches: [[name: '*/development']],
>>> extensions: [
>>> [$class: 'CleanBeforeCheckout'],
>>> [$class: 'SubmoduleOption',
>>> disableSubmodules: false, parentCredentials: true,
>>> recursiveSubmodules: true,
>>> reference: '', trackingSubmodules: false]],
>>> doGenerateSubmoduleConfigurations:
>>> false, submoduleCfg: [],
>>> userRemoteConfigs: [[credentialsId:
>>> 'mvs-randall',url: 'g...@xx.xxx.xxx.xxx:proj/repo.git']]])
>>>
>>> Both result in Permission denied (publickey).
>>>
>>> I've done the same thing on many other platforms with no problem. This
>>> seems very R2.4 specific. There was a change in the supported file
>>> encodings as well - we used to use -Dfile.encoding=utf8 in the agent config
>>> (because this is an IBM that likes EBCDIC), but had to move to
>>> -Dfile.encoding=ISO8859-1 and everything seems messed up now. IBM had this
>>> funky script they recommend that massages the key into an IBM-1047 encoding
>>> but that does not help at all - in fact the GitSCM agent cannot process any
>>> results if that script is used.
>>>
>>> Help!
>>>
>>> TIA,
>>> Randall
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com
>
> .
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHp9izxgfqe5w3U1YoaY4uSeoNaQwKLd5kWWRfkW1nV%2BA%40mail.gmail.com.
Create default admin user on Jenkins own user database
Dear Team, As part of automation, I need to create and invoke Jobs using Jenkins API. I have deployed jenkins container on Kubernetes cluster using helm chart. Hence I need Jenkins to have at least one admin user in its own database (Jenkins' own user database) after install. By default, its Delegate to servlet container . How to do it ? Could you help me. Thanks -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ca3d8119-9fe4-4373-9048-671db3219d9do%40googlegroups.com.
Re: SSH Agent, z/OS USS, and git authentication problems
I wish it was that simple. The issue definitely appears to be the encoding
of the private key during a key exchange. When using SSH-Agent and git
commands from within a shell in the pipeline, the authentication works
fine. So this is likely an interaction with the GitSCM plugin not being
aware of IBM-1047 encodings.
On Sunday, 12 July 2020 16:08:31 UTC-4, Ivan Fernandez Calvo wrote:
>
> I think that this is the reason why it does not work
> https://support.cloudbees.com/hc/en-us/articles/224910467-Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-
>
> El sábado, 11 de julio de 2020, 22:25:08 (UTC+2), Randall Becker escribió:
>>
>> I'm having issues trying to get an agent to authenticate using the SSH
>> Agent plugin on a R2.4 z/OS USS agent with a Docker Jenkins controller. The
>> goal is to convince GitSCM to actually fetch properly. We get SSH
>> authentication errors no matter what happens. This is using Pipelines.
>>
>> I've tried
>> sshagent (credentials: ['mvs-randall']) {
>> checkout([$class: 'GitSCM',
>> branches: [[name: '*/development']],
>> extensions: [
>> [$class: 'CleanBeforeCheckout'],
>> [$class: 'SubmoduleOption',
>> disableSubmodules: false, parentCredentials: true,
>> recursiveSubmodules: true,
>> reference: '', trackingSubmodules: false]],
>> doGenerateSubmoduleConfigurations:
>> false, submoduleCfg: [],
>> userRemoteConfigs: [[url:
>> 'g...@xx.xxx.xxx.xxx:proj/repo.git'']]])
>> }
>> and
>> checkout([$class: 'GitSCM',
>> branches: [[name: '*/development']],
>> extensions: [
>> [$class: 'CleanBeforeCheckout'],
>> [$class: 'SubmoduleOption',
>> disableSubmodules: false, parentCredentials: true,
>> recursiveSubmodules: true, reference:
>> '', trackingSubmodules: false]],
>> doGenerateSubmoduleConfigurations: false,
>> submoduleCfg: [],
>> userRemoteConfigs: [[credentialsId:
>> 'mvs-randall',url: 'g...@xx.xxx.xxx.xxx:proj/repo.git']]])
>>
>> Both result in Permission denied (publickey).
>>
>> I've done the same thing on many other platforms with no problem. This
>> seems very R2.4 specific. There was a change in the supported file
>> encodings as well - we used to use -Dfile.encoding=utf8 in the agent config
>> (because this is an IBM that likes EBCDIC), but had to move to
>> -Dfile.encoding=ISO8859-1 and everything seems messed up now. IBM had this
>> funky script they recommend that massages the key into an IBM-1047 encoding
>> but that does not help at all - in fact the GitSCM agent cannot process any
>> results if that script is used.
>>
>> Help!
>>
>> TIA,
>> Randall
>>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/1ece555d-921d-4a66-ba9d-2afe1cf212fao%40googlegroups.com.
How to get hudson.security.ArtifactsPermission work properly.
I set this permission from the jenkins scripts console as :
System.setProperty("hudson.security.ArtifactsPermission", "true")
But after doing this I'm not able to see any artifacts in any of the
jenkins jobs(even with authenticated user).
I thought that after adding this permission a new security rule will come
up in the role based strategy or somewhere else. But I can't find anything.
Can anyone let me know how to use this properly? Basically I want to allow
artifacts access to anonymous users.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/41a144de-a395-44a2-9d23-9a00c28912eeo%40googlegroups.com.
Re: Jenkins - Docker login doesn't seem to persist
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-latest docker-common
docker-latest docker-latest-logrotate
docker-logrotate docker-engine
3 yum install -y yum-utils
4 yum-config-manager --add-repo https:
//download.docker.com/linux/centos/docker-ce.repo
5 yum install docker-ce docker-ce-cli containerd.io
6 systemctl start docker
7 docker ps
8 docker run hello-world
9 docker login https://nexus:port
10 docker login https://nexus:port
11 docker pull nexus:port/company/image:tag
# docker pull nexus:port/company/image:tag
...
Status: Downloaded newer image for nexus:port/company/image:tag
While I still have the faulty behaviour when I install docker via "yum
install -y docker". So it's pretty clear to assume that I'm not facing an
issue with the Jenkins Docker images specifically but rather face centos
problems with their Docker package.
I guess there is no need here for an answer. I will go on to talk to the
centos people.
Cheers and thanks for your consideration everyone!
Am Freitag, 10. Juli 2020 16:24:22 UTC+2 schrieb Sven Hüßner:
>
> Cheers guys,
>
> I am fiddling with an issue I have described at the devops stackexchange
> fairly closely, I hope. I feel like I'm arriving where I should ask in this
> mailinglist to see if I'm on the right track.
>
> In a nutshell: I am running a jenkins/jenkins container (more about the
> used tags below) as "Docker in Docker". So my Jenkins is a Docker container
> and my pipelines will instruct Jenkins to run more Docker containers.
>
> Before we dive into pipelines and everything, I run into an issue with
> "docker login" to our Nexus. Do not worry, I don't think this will be a
> Nexus issue:
>
> [root@909fb3a3d52c .docker]# docker login https://nexus:port
> Username: jenkins
> Password:
> Login Succeeded
> [root@909fb3a3d52c .docker]# pwd
> /root/.docker
> [root@909fb3a3d52c .docker]# cat config.json
> {
> "auths": {
> "https://our.nexus.internal:": {
> "auth": ""
> }
> }
>
> So I would assume the login succeeded, juding by both the message and the
> correct base64 hash in the config file.
>
> However:
> [root@909fb3a3d52c .docker]# docker pull https://nexus.port/myImage:myTag
> Error response from daemon: Get
> https://nexus:port/v2/myImage/manifests/myTag:
> no basic auth credentials
>
> This will also be the result of any pipeline execution of course:
>
> + docker pull https://our.nexus.internal:/myImage:myTag
>
> Error response from daemon: Get Error response from daemon: Get
> https://our.nexus.internal:/v2/myImage/manifests/myTag:
> no basic auth credentials
>
> script returned exit code 1
>
> The curious thing:
> If I run a "docker-compose up" with a compose file using the same image it
> pulls fine. If I use the debian based jenkins/jenkins:latest instead
> of jenkins/jenkins:lts-centos7 it pulls fine as well.
>
> Pls go ahead and check the details on those two on the devops
> stackexchange question:
> https://devops.stackexchange.com/questions/11981/jenkins-docker-login-doesnt-seem-to-persist-docker-pull-wont-work-but-docke
>
> So I am assuming something about the lts-centos7 image tag?
>
> Maybe you guys can shine some additional light, I am uncertain where to
> look further, but strongly willing to investigate :)
>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/40d283ef-3cee-478d-8910-49821e50bbdao%40googlegroups.com.
