Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    hervelemeur
    @hervelemeur:matrix.org
    [m]
    🤷
    search it manually ;)
    hervelemeur
    @hervelemeur:matrix.org
    [m]
    :point_up: Edit: 🤷
    search "jenkinsci/configuration-as-code" manually ;)
    Rein Petersen
    @ReinsBrain

    :point_up: Edit: 🤷
    search "jenkinsci/configuration-as-code" manually ;)

    found it! thanks :)

    Mayhem Bill
    @MayhemBill
    okay, I'm not sure what I'm doing wrong, but I am running Jenkins in Docker, and I am trying to create an image from a dockerfile, but when I try to run the docker command in the container I get a permission denied, and anything I change in the Jenkins container just gets reset after a reboot
    dduportal
    @dduportal:matrix.org
    [m]

    Hello @timja @MarkEWaite I'm investigating jenkinsci/docker-inbound-agent#279 and I discovered that the build of the main branch does NOT use the "latest" released version:

    Should we slighlty change the release process for this (and jenkins/agent as well)?

    FWIW, I'm opening a PR to leverage the risk + bump the version
    Tim Jacomb
    @timja
    @dduportal:matrix.org not sure I understand the issue
    it would be easier if they were in the same repository
    dduportal
    @dduportal:matrix.org
    [m]
    @timja: what is the "usual" release process for the docker images of the jenkins agents? Is it the draft release being published? (I wonder given the new version scheme is used, if there is a CD process ?)

    it would be easier if they were in the same repository

    +100

    Tim Jacomb
    @timja
    it's not using a new version scheme
    it uses the remoting version
    and versions always match that
    dduportal
    @dduportal:matrix.org
    [m]
    I though that the suffix -X was specific to the images, doesn't it?
    Tim Jacomb
    @timja
    the release process is, release the docker-agent repo via github releases.
    trigger it on trusted.ci.
    once green release docker-inbound-agent via github releases
    trigger it on trusted.ci
    yes it is that is extracted from the tag
    dduportal
    @dduportal:matrix.org
    [m]
    Ok, so the release process looks flawed: I would expect the "remoting version" to be infered from the tag then, right ?
    Tim Jacomb
    @timja
    it is inferred
    dduportal
    @dduportal:matrix.org
    [m]
    Oh i see. Then we should NOT deploy images if the build is not triggered by a tag
    Tim Jacomb
    @timja
    yes i don't think there's much point in that
    and yeah main branch uses whatever is there
    / tests
    dduportal
    @dduportal:matrix.org
    [m]
    gotcha.
    Tim Jacomb
    @timja
    that should be updated every now and then but generally doesn't need to be touched
    dduportal
    @dduportal:matrix.org
    [m]
    first thing first: the default values from the Dockerfile should be removed then
    then, we should either:
    • Add an updatecli/depedndanbot/whatever to update the version on the bake file
      OR
    • not specify a version and autodetermien it with a call to the gh api e.g." get the latest version")
    Tim Jacomb
    @timja
    the defaults are there so that the image builds with just a docker build
    and same in the bake file
    and yes the master / tests could auto determine it but I don't think that's great for deterministic builds
    updatecli to update everything would be fine
    dduportal
    @dduportal:matrix.org
    [m]

    the image builds with just a docker build

    I understand this was the constraint with DockerHub in the past, but I don't see the point nowadays?

    updatecli to update everything would be fine

    👍️

    Tim Jacomb
    @timja
    nice to be able to just docker build it for testing something
    dduportal
    @dduportal:matrix.org
    [m]
    ok, so the updatecli needs to update all references
    sounds like a job for grep and sed :D
    Tim Jacomb
    @timja
    :)
    dduportal
    @dduportal:matrix.org
    [m]
    @timja: jenkinsci/docker-inbound-agent#280 as first step (to stop pushing from main branch + fixing the unexpected tag builds)
    dduportal
    @dduportal:matrix.org
    [m]

    For information, I've manually updated the tag v38db_38a_b_7a_86-2 on the image jenkins/docker-agent with the following command: git tag 3046.v38db_38a_b_7a_86-2 3046.v38db_38a_b_7a_86-2^{} -f -a && git push upstream v38db_38a_b_7a_86 --force. The GitHub release did not change and points to the updated tag: https://github.com/jenkinsci/docker-agent/releases/tag/3046.v38db_38a_b_7a_86-2 (as the git ref did not change).

    The reason was to annotate the tag so it's seen as the latest (before the change, 4.13-2 was still the "most recent")

    dduportal
    @dduportal:matrix.org
    [m]
    @MarkEWaite: I was mistaken: this function (and the associated sorting issue) is used by the image entrypoint, when it lists plugins to deploy into the jenkins_home/plugins from /usr/share/jenkins/ref (as @timja pointed me out)
    So the snippet from @dipjul might solve the issue, but did not have time to verify yet
    sealor
    @sealor:matrix.org
    [m]

    Hello everyone!

    I read that I can execute a groovy script on the first Jenkins start-up.
    Is it also possible to somehow run a groovy script at Docker build time?

    2 replies
    papi83dm
    @papi83dm
    My docker jenkins keeps running out of memory, how do I determine what is using the memory and how much memory I need to allocate? its currently running with 8GB of ram.
    halkeye
    @halkeye:g4v.dev
    [m]
    sealor: lemme rephrase. What operations would you want to do on build time? those init scripts are run time
    2 replies
    dduportal
    @dduportal:matrix.org
    [m]
    @timja: about the release-drafter PR I made on the docker-inbound-agent. I'm looking at https://github.com/jenkinsci/jenkins-infra-test-plugin/blob/master/.github/workflows/cd.yml to see what the call to the reusable action would look like. I feel like in this case it's the same amount of information in the YAML, only to reuse the action version. Did I miss something?
    Tim Jacomb
    @timja
    @dduportal:matrix.org it's one central place to update versions
    i.e. so release drafter sends an update
    only one place gets a dependabot update