Comments
Sort by recent activity
FYI I got this working by giving the service account running the SQL Backup Agent access to the network share. / comments
FYI I got this working by giving the service account running the SQL Backup Agent access to the network share.
Kendra - yes we can make a small database change, especially if we move forward with the creation of a database for this purpose as you have suggested. Thanks for your help with this. / comments
Kendra - yes we can make a small database change, especially if we move forward with the creation of a database for this purpose as you have suggested. Thanks for your help with this.
I am not able to reproduce this behavior. When I commit a post-deployment script to Git, it is not deployed unless I also include a database schema change. / comments
I am not able to reproduce this behavior. When I commit a post-deployment script to Git, it is not deployed unless I also include a database schema change.
Kendra, Thanks for your detailed and prompt reply. This sounds like a good solution, but I'll still need to make some kind of change to the InstanceConfiguration database so that my pre/post deployment scripts will run. Agree? I suppose this could be a static data change rather than an actual schema change. Tom / comments
Kendra,Thanks for your detailed and prompt reply.This sounds like a good solution, but I'll still need to make some kind of change to the InstanceConfiguration database so that my pre/post deployme...
Yes. SQL Source Control / State Based + SQL Change Automation. I tried this again just now with the same result.I made a harmless change to my post-deployment script. SQL Source Control listed this on the Commit tab. I committed it to Git and pushed it. My build/deploy process (Jenkins/Octopus) kicked off, but the script artifact in Octopus contains only the following: /* Generated on 24/Apr/2019 10:24 by Redgate SQL Change Automation v3.1.16.3737 This script is empty because the Target and Source schemas are identical. */ / comments
Yes. SQL Source Control / State Based + SQL Change Automation. I tried this again just now with the same result.I made a harmless change to my post-deployment script. SQL Source Control listed thi...
This was solved using Jenkins multi-branch pipelines. Any Git branch will build now when a push or merge is done, and I only need one Jenkins project for each database. / comments
This was solved using Jenkins multi-branch pipelines. Any Git branch will build now when a push or merge is done, and I only need one Jenkins project for each database.
Thanks, but that did not seem to help. I added the Additional Behaviour with my repos name and "origin/test" as the branch, but the GitHub Hook Log still reports "No changes". Is there some way to avoid this check (for No changes) altogether? If Git does a push, I want Jenkins to do a build. / comments
Thanks, but that did not seem to help. I added the Additional Behaviour with my repos name and "origin/test" as the branch, but the GitHub Hook Log still reports "No changes". Is there some way to ...
I'm starting to think this is not possible with a single Jenkins project. I found a few posts about this but no good solutions: https://stackoverflow.com/questions/19283187/jenkins-does-not-build-branch-after-merging-with-another-one https://github.community/t5/How-to-use-Git-and-GitHub/Trigger-Jenkins-job-when-a-pull-request-is-merged-to-a-branch/td-p/10190 https://stackoverflow.com/questions/41660240/jenkins-wont-trigger-build-after-merging-a-pull-request-in-github The only thing I can think of is create four Jenkins projects for each database; one to build the feature branches, and one each for Test/Staging/Production. This is not ideal because I have about 25 databases to deal with, but it would largely be a one-time setup. I don't quite understand the Jenkins multi-branch pipelines but that might a more compact way to this. / comments
I'm starting to think this is not possible with a single Jenkins project. I found a few posts about this but no good solutions:https://stackoverflow.com/questions/19283187/jenkins-does-not-build-br...
Thanks again. This is coming together. Do you recommend using Git to do the merge, or SQL Source Control? The first approach works fine although you don't get the visual difference report the way you do with SQL Source Control. That said, I'm having trouble with the latter approach. Let's say I do the following: Create a new branch named Issue1 from master Code a change (e.g. add a column) and check it in At this point Jenkins starts a build and all is well. However, if I then checkout master (using git checkout), SQL Source Control thinks the Git version (in master) is more recent than what's in my database and shows the column deletion on the Get Latest tab. The Commit tab is empty. This is obviously not what I want. Thoughts? / comments
Thanks again. This is coming together. Do you recommend using Git to do the merge, or SQL Source Control? The first approach works fine although you don't get the visual difference report the way y...
Thank you both for your replies. Pushing all the branches through our DevOps process does indeed seem to solve this, although I have not finished thinking this through. For example, suppose branch Issue1 is pushed into our Test environment and is approved for Production. Do we just deploy that branch, or do we go back and merge the changes into master and repeat the Test/Production cycle? Either way this will require some coordination between developers but that is the case even without an automated DevOps solution. / comments
Thank you both for your replies. Pushing all the branches through our DevOps process does indeed seem to solve this, although I have not finished thinking this through. For example, suppose branch ...