Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43079

Move publishing to "trusted" location (via parametrised job)

    • Blue Ocean - 1.1-beta-1, Blue Ocean - 1.1-beta2, Blue Ocean 1.1-beta4, Blue Ocean 1.1

      Ideally the publishing of the blueocean-plugin multimodule would be moved to a (parametrised?) job on ci.jenkins.io, or some "standard and secure" location so published can be performed on demand by multiple users. 

       

      This may involve a release branch, or a parametrised job, not sure. We need to find out what the "standard" process is (if there is one).  

      I think we can't use dogfood as it is not a "trusted" environment for credentials, due to it running frequently updated and experimental versions of itself. Publishing should be like the official docker image which is published on jenkins.io secure infrastructure. (need to talk to KK about best way for this).

       

      In scope:

       

      • A jenkins setup to host deployments that is "trusted"
      • github token and settings.xml to allow deployment
      • A pipeline to allow parametrised deployment from a given branch usign batch mode mvn release:prepare release:deploy

       

          [JENKINS-43079] Move publishing to "trusted" location (via parametrised job)

          Michael Neale added a comment -

          vivek one idea for this: we really need to test this on some release, but obviously not on a non beta. 

          I say that we change the version in pom.xml on master to be a "beta" for 1.1 (so it goes to the beta UC). We can then work on doing a first fully automated release of that from trusted infra with secrets, to shake it down/get it working how we want. 

          Would make sense to do it that way, no? 

          Michael Neale added a comment - vivek one idea for this: we really need to test this on some release, but obviously not on a non beta.  I say that we change the version in pom.xml on master to be a "beta" for 1.1 (so it goes to the beta UC). We can then work on doing a first fully automated release of that from trusted infra with secrets, to shake it down/get it working how we want.  Would make sense to do it that way, no? 

          Vivek Pandey added a comment -

          michaelneale Yeah, sounds good, this will ensure we don't accidentally release it outside. We can change it to non-beta once we are done with testing and ready to release 1.1, some hassle but not a big deal.

          Vivek Pandey added a comment - michaelneale Yeah, sounds good, this will ensure we don't accidentally release it outside. We can change it to non-beta once we are done with testing and ready to release 1.1, some hassle but not a big deal.

          Michael Neale added a comment -

          FYI the builds are working on the private server now - the problem with the authorize project plugin. We don't have workable user scoped credentials yet - but maybe we can make do anyway... 

          Michael Neale added a comment - FYI the builds are working on the private server now - the problem with the authorize project plugin . We don't have workable user scoped credentials yet - but maybe we can make do anyway... 

          Vivek Pandey added a comment -

          With current approach we do not need build authorize plugin. I will remove this plugin. 

          Vivek Pandey added a comment - With current approach we do not need build authorize plugin. I will remove this plugin. 

            vivek Vivek Pandey
            michaelneale Michael Neale
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: