Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 29 18:44

    batmat on master

    [JENKINS-55842] Exceptions shou… Merge pull request #381 from ba… (compare)

  • Jan 29 18:44
    batmat closed #381
  • Jan 29 16:46
    batmat edited #381
  • Jan 29 16:44
    batmat review_requested #381
  • Jan 29 16:44
    batmat review_requested #381
  • Jan 29 16:44
    batmat opened #381
  • Jan 29 15:10
  • Jan 29 00:05

    rtyler on master

    Update various plugins Latest … Merge pull request #380 from ba… (compare)

  • Jan 29 00:05
    rtyler closed #380
  • Jan 28 22:22
    batmat review_requested #380
  • Jan 28 22:22
    batmat review_requested #380
  • Jan 28 22:22
    batmat opened #380
  • Jan 28 13:49

    batmat on master

    Bump to Jenkins 2.162 Especial… Merge pull request #379 from ba… (compare)

  • Jan 28 13:49
    batmat closed #379
  • Jan 28 13:47
    batmat reopened #379
  • Jan 28 13:47
    batmat closed #379
  • Jan 28 09:50
    batmat edited #379
  • Jan 28 09:49
    batmat review_requested #379
  • Jan 28 09:49
    batmat opened #379
  • Jan 25 07:39
    ruairitobrien starred jenkins-infra/evergreen
Daniel Beck
@daniel-beck
More of a question for jenkinsci/configuration-as-code-plugin then? Or does it result in un-workaround-able problems with Evergreen and the use case is separate from plain CasC?
R. Tyler Croy
@rtyler
We don't have the ability to push configuration-as-code modifications to Evergreen instances, which means they would all hard crash if we rolled out the latest cores :laughing:
if you've got no desire to put a symbol compatibility shim into core, then this is all a moot point
Daniel Beck
@daniel-beck
If it can be done with minimal side effects, not opposed
R. Tyler Croy
@rtyler
I think @batmat's suggestion of cramming that into the Evergreen plugin is our only safe option
Daniel Beck
@daniel-beck
but something like this should be expected IMO, I'm kind of surprised it took so long to surface
R. Tyler Croy
@rtyler
should be expected by whom?
Daniel Beck
@daniel-beck
designers of evergreen update protocol, if it relies on casc to this extent
R. Tyler Croy
@rtyler
the sharp edges of configuration as code have already bitten us plenty of times, this is the first scenario where a core upgrade crashed things with previously valid configuration though
Daniel Beck
@daniel-beck
hm
and it's sufficiently different to those previous problems that the same workarounds/fixes cannot be applied?
R. Tyler Croy
@rtyler
considering I have never seen us actually delete anything from core, I must admit I did not plan for this scenario :laughing:
and good morning @MarkEWaite :)
Daniel Beck
@daniel-beck
@rtyler FYI this likely won't be the last time either: jenkinsci/jenkins#3970
R. Tyler Croy
@rtyler
I'm definitely not opposed to deleting code
Baptiste Mathus
@batmat
Yeah, likely the option using the plugin to do these is indeed going to be the simplest path, given we didn't have the time to finalize the evergreen-client auto-update side.
R. Tyler Croy
@rtyler
I was looking on the bus this morning and couldn't figure out how to simply add a stub struct from the casc dev docs :/
Baptiste Mathus
@batmat
jenkinsci/evergreen-plugin#20 should help us move forward on #404, and relates to #407
batmat @batmat needs to go sleeping. Holiday for moar rechargin'
Baptiste Mathus
@batmat
o/
batmat To be continued
R. Tyler Croy
@rtyler
heh, I saw that, thanks
been busy working so haven't had a chance to look at your pull requests today
Baptiste Mathus
@batmat
(Crappy gitter app), ^ demonstrates the evergreen plugin patch
R. Tyler Croy
@rtyler
:wave:
Baptiste Mathus
@batmat
o/
Derek Bennett
@DerekBennett
I am having a problem accessing the host docker from within pipelines. The following command WORKS:
docker exec -it evergreen docker info
from my host command-line. But, when I go to run a pipeline with a docker agent, or with just docker info, I get
"Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"
Does anyone have any ideas how to solve this?
Derek Bennett
@DerekBennett
docker exec -it evergreen docker run --rm maven:3-alpine mvn -version
works, but this pipeline fails with the error message from above
pipeline {
agent {
docker {
image 'maven:3-alpine'
}
}
stages {
stage('build') {
steps {
sh 'mvn -version'
}
}
}
}
To me, this looks like the same thing. What is the "agent" doing that is cutting it off from the host's Docker instance?
R. Tyler Croy
@rtyler
docker exec -it evergreen docker run --rm maven:3-alpine mvn -version I haven't actually seen an invocation like that before, I'm not clear what this is doing
in terms of whether it's using the ricght socket, etc
Derek Bennett
@DerekBennett
The idea was to simulate the way that mvn is being invoked inside of evergreen. What should happen is that the interior Docker client should see the docker.sock that was mapped-in on Evergreen start-up.
You could break it up like this:
docker exec -it evergreen bash
and then
docker run --rm maven:3-alpine mvn -version
R. Tyler Croy
@rtyler
when you run the pipeline above, I presume you see a jnlp agent container come online?
Derek Bennett
@DerekBennett
I don't know where to observe that.
R. Tyler Croy
@rtyler
ctop is really handy on the host, or just by seeing in the Jenkins classic UI whether an agent is provisioned correctly
my hunch here is that a container is being created, and then within that container we are again trying to execute more dockery things, but the mapping of the socket hasn't happened
Derek Bennett
@DerekBennett
I tried this sort of agent declaration:
agent {
docker {
image 'maven:3-alpine'
args '-v /var/run/docker.sock:/var/run/docker.sock'
}
}
with no luck
R. Tyler Croy
@rtyler
hrm, that is a bummer
R. Tyler Croy
@rtyler
hah, now that Uplink has stopped saturating the quota of Sentry errors, we can see errors from Evergreen again :clap:
Derek Bennett
@DerekBennett

The secret sauce for me was to remove firewall blocking

Remove firewall blocking 8080

https://serverfault.com/questions/871597/unable-to-access-jenkins-centos-7

https://hostpresto.com/community/tutorials/how-to-install-jenkins-on-centos-7/

sudo firewall-cmd --zone=public --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

Craig Andrews
@candrews
I have a number of PRs created against Evergreen: hhttps://github.com/jenkins-infra/evergreen/pulls/candrews Can someone please take a look at them?
R. Tyler Croy
@rtyler
@candrews I just saw those in my inbox this morning, I'll try to get to them later tonight PDT
Craig Andrews
@candrews
rtyler, that's awesome! Thank you very much. I have a couple more than I'll be making too (using an EIP for the Jenkins EC2 instance so the IP doesn't change when the instance is replaced, and using a Cloudwatch Alarm to recover the EC2 instance if the instance status check fails)
R. Tyler Croy
@rtyler
@candrews we haven't done much testing around Evergreen on AWS in this manner, @batmat and I focused much more on just the Docker workflows
Craig Andrews
@candrews
I suppose I'm blazing the trail then :)
As long as you can review/merge my PRs, I'm willing to do the leg work and testing :)
Craig Andrews
@candrews
rtyler, is it possible to merge these 3? Together, they allow running Evergreen on a region other than us-east-1, and that's really important to me :) jenkins-infra/evergreen#439 jenkins-infra/evergreen#440 jenkins-infra/evergreen#441
kshitishdevops
@kshitishdevops
Hi while executing jenkins.yaml file I am getting below errors:
io.jenkins.plugins.casc.ConfiguratorException: Item isn't a Scalar
at io.jenkins.plugins.casc.model.CNode.asScalar(CNode.java:26)
at io.jenkins.plugins.casc.impl.configurators.PrimitiveConfigurator.configure(PrimitiveConfigurator.java:45)
at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.tryConstructor(DataBoundConfigurator.java:161)
at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.instance(DataBoundConfigurator.java:77)
at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:268)
at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.configure(DataBoundConfigurator.java:83)
at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.tryConstructor(DataBoundConfigurator.java:153)
at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.instance(DataBoundConfigurator.java:77)
at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:268)
at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.configure(DataBoundConfigurator.java:83)