Recently I migrated Gerrit on new machine. As part of migration, I took the mysqldump and restored it on new gerrit machine. I ran the reindex operation after restore but the problem is I am not able to see all the reviews on Gerrit UI even if I see them in database table called changes
As #StephenKing mentioned, there was error in reindexing. The error got fixed when I rsynced managed git repositories from old to new gerrit. Once reindex was successful, all changes appeared on UI
Related
Setup:
Dev slot with slot setting to a DEV database
Production slot with slot setting to a PRODUCTION database.
I enabled 'Execute Code First Migration' on my publish profile and publish onto the DEV slot. The DEV database gets updated perfectly.
But when swapping my slot to PROD the Code First Migration isn't being executed on the PROD database.
We have multiple customers that need this setup. I want developers to setup the new version onto the DEV slot and I want my project managers to SWAP it when they feel the customer is ready to receive the new version and this way they can demo the new version immediately. I don't want them doing any more additional actions.
For now I have made a fix that makes them browse to an URL in the app that will execute any missing updates via the following piece of code:
var configuration = new Configuration();
var migrator = new DbMigrator(configuration);
migrator.Update();
It is normal that the migration isn't getting triggered when swapping the slots?
Do you have the connection string configured as a slot-specific setting? If so your worker process should restart on swap. And you just need to ensure migrations run on startup. Apparently the configuration changes made by the publishing profile to cause migration to run on startup aren't propagated into the production slot.
See this post on the ASP.NET blog for options: EF Code First Migrations Deployment to an Azure Cloud Service
How can I enable auto fork syncing on BitBucket cloud ? I cant find the option and have to manually keep the fork updated.
Thanks!
While originally I found this article, it seems this only applies to their server product: https://confluence.atlassian.com/bitbucketserver/keeping-forks-synchronized-776639961.html
This article indicates that its a process you will need to manage manually on local:
https://confluence.atlassian.com/bitbucket/forking-a-repository-221449527.html
After you fork a repository, the original repository is likely to continue to evolve as other users commit changes to it. These changes do not appear in your fork. However, you can pull these changes into your fork later by syncing changes locally from the command line.
While this describes pulling upstream manually, you could probably script something to do this more automatically for your purposes. If I end up doing something like this for our team, I'll update this answer with more details or perhaps someone else will do the same.
Recently, in our enterprise production setup, it seems someone has tried to setup a new job / test definition by using another (copying) from identical job. However, (s)he seems to have NOT saved (and probably, am guessing here, closed the browser with the session being lost).
But the new job got saved though it was not set to stable or active; we knew about this because changes uploaded to gerrit, started failing in this newly setup partial job (because, these changes were in certain repos that met certain TDD settings).
Question: Jenkins system does not have trace of who setup the system in 'configure versions' option. Is there anyway to know the details of who setup the job / when was that done ?
No, Jenkins does not store that information by default.
If your Jenkins instance happen to be running behind an Apache or Nginx web server, there might be access logs that can help you. To find out when the job was created you could look at when its config.xml file was created/modified.
However, there are a few plugins that can add this functionality so that you won't have this problem again:
JobConfigHistory Plugin – Tracks changes in your job configurations and gives the ability to restore old versions.
Audit Trail Plugin – Keeps a log of who performed particular Jenkins operations, such as configuring jobs.
Is it possible to trigger a server update via Capistrano on the actual deployment server, so it fetches updates rather than them being pushed to it?
Our customer's server config is locked down from external access, so can't push an update to it (but it can get to the interwebs, so could see a repository somewhere)
I can't believe I'm inventing something new here, so is it possible to visit and admin page in the app to find an update is available and stop/update/restart the server? What do other people do?
Just to finally close this off, we solved this eventually by moving the project tot gitlab.com and using a gitlab-runner to poll for deployments - thus, pulling updates, not having them pushed.
On Gerrit Web UI, I do not see a way to purge Change-Ids in "Abandoned" state.
While trying out Gerrit we created a good number of Change-Ids that are required to go
away from the Web UI.
Is cleaning from DB directly using SQL scripts, the only alternative?
Gerrit: version 2.4.2
OS: RedHat Based
Please let me know if you require any additional information.
Thanks
Yes, purging the DB is the only way (currently) to completely delete changes. They also will still exist in the repository under the refs/changes/ branch, but won't show up in the Web UI once the database has been purged.