Jenkins is set up to pull and build from the SVN repository, no automated trigger. I plan to trigger the build manually. The build will also package and push to Octopus.
User accesses Octopus, maybe click a button and trigger the Jenkins build.
The Jenkins build creates a new release in Octopus.
User deploys the new release to TEST
Is this plausible? We have sort of an inexperienced developers. They commit trivial changes to our repository so I don’t want to automate the releasing and pushing of the packages every time a commit is made.
You should be able to trigger a build using a PowerShell script step and using the Jenkins API. It’s definitely not how we like to think about things since the progression should usually move forward form CI to CD and not backwards, but may work for you. The deploy release step may also be of particular interest to you. Is the call back to Jenkins absolutely necessary considering you will be triggering the release build manually from Jenkins?
In this scenario however, CI is probably not required most of the time. It sounds like enabling CI only for the master branch while forcing all devs to group related changes into branches and periodically merging would be the best solution, however may be more challenging.