Question inline for a specific plugin, but the question may be general enough to merit discussion.
On Tuesday, June 20, 2017 at 7:29:33 AM UTC-6, Stephen Connolly wrote: > > OK! Here we are... testing time! > > These are the plugins that are being covered: (download links should be > live in an hour or two) > > scm-api 2.2.0-alpha-1 > https://updates.jenkins.io/download/plugins/scm-api/2.2.0-alpha-1/scm-api.hpi > branch-api 2.0.11-alpha-1 > https://updates.jenkins.io/download/plugins/branch-api/2.0.11-alpha-1/branch-api.hpi > git 3.4.0-alpha-1 > https://updates.jenkins.io/download/plugins/git/3.4.0-alpha-1/git.hpi > mercurial 2.0-alpha-1 > https://updates.jenkins.io/download/plugins/mercurial/2.0-alpha-1/mercurial.hpi > github-branch-source 2.2.0-alpha-1 > https://updates.jenkins.io/download/plugins/github-branch-source/2.2.0-alpha-1/github-branch-source.hpi > cloudbees-bitbucket-branch-source 2.2.0-alpha-1 > https://updates.jenkins.io/download/plugins/cloudbees-bitbucket-branch-source/2.2.0-alpha-1/cloudbees-bitbucket-branch-source.hpi > > Recommended testing procedure: > > 1. Set up a throw-away Jenkins running a version similar to your > production environment *with the pre-upgrade versions of the plugins you > are using*. > 2. Set up ideally at least one organization folder and one standalone > multibranch project building your source code - to a first order you do not > care if the builds succeed or fail, only that the branches are found. > 3. Trigger a scan / index of your organization folders and standalone > multibranch projects. > 4. Wait for the queue to complete > 5. Run the script in the system script console: > https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and > save the output to smoke-pre-upgrade.txt > 6. Upgrade the relevant plugins, restart Jenkins. > 7. Run the script in the system script console: > https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and > save the output to smoke-post-upgrade.txt > 8. Trigger a scan / index of your organization folders and standalone > multibranch projects. > 9. Wait for the queue to complete > 10. Run the script in the system script console: > https://gist.github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and > save the output to smoke-post-rescan.txt > > At this point, do a diff between smoke-pre-upgrade.txt and > smoke-post-rescan.txt > > You are looking for three classes of difference: > > a. branch jobs that have been rebuilt for no reason (i.e. the revision is > the same) > b. branch jobs that have disappeared for no good reason (i.e. the branch > is still present in the backing scm) > c. branch jobs that have suddenly appeared for no good reason (i.e. the > branch was there before but not found) [expecting some of these for > BitBucket PRs from forks, but only after configuration updated, saved and > another rescan performed] > > My expectation is that nobody will have these kinds of issues. > > Also try out the new UI to see what you think. > > Please report back your testing results either way. Don't forget to report > back your UI feedback too ;-) > > After doing that test in a throw-away Jenkins, you can *optionally* repeat > the test on a *more* production*-like* (emphasis on being production-like > not production) instance... but this is code that has not yet completed > code review (hence -alpha-1 not -beta-1) so it is at your own risk. There > are additional issues to be aware when using more production-like > environment: > > a. You may have builds that were assuming branches were full clones, now > the refspec is tightly reduced to minimize clone time. If you need a full > clone you will need to add the "Advanced Clone" behaviour. > The git client plugin has tests which assume its branches are full clones. It uses that assumption to reduce the setup time for submodule tests, tests of tagging, and more. It also uses the global pipeline library in its Jenkinsfile so that the Jenkinsfile is a single line "buildPlugin". I very much like the single line "buildPlugin" Jenkinsfile. I'm willing (if necessary) to rework the git client plugin tests so that it no longer assumes branches are full clones. Unfortunately, time spent reworking those tests will be time that is not spent reviewing pull requests or testing new ideas. Is there a way that I can keep the convenience and power of buildPlugin() without burdening other plugin developers with the weight of a full clone? Mark Waite -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/77d6566b-1df0-4fec-aa46-5c677ba0a1cb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
