for the first time I updated an app with the jhipster upgrade command.
It seems all ok but at the end of the updating it noticed me about three conflicts that I have to resolve manually.
My first problem is: how to update the Liquibase scripts?
In this case, have been added some uniqueConstraintName but I can't to add them in my scripts because they have already been executed.
So, which is the best solution? Don't update the scripts? Mark them as merged? Add manually another script in order to add these constraints?
And how I have to solve other conflicts like the image below?
Simply copy and paste from new file to old file?
Thanks a lot,
Andrea
If you have a live database, then you must not upgrade your liquibase scripts but add new ones to do the migration. What you can do is running the new scripts against a blank dev database (same type of db as prod), then revert to old scripts, then call ./mvnw liquibase:diff to get the delta script, then add the delta script to the scripts to run.
Related
Yesterday, I have moved my GitLab installation to another machine.
It was installed with docker-compose, and I followed the official GitLab guide to back up and restore GitLab including the 'secrets' files.
Everything works so far, except the CI/CD variables in the admin area.
I get the error 'There was an error fetching the variables.' when I navigate to this site.
Can you give me a hint in which log I can found more information about this error?
Finally I could solve the problem.
With the Doctor Rake tasks I could determine where the problem was.
Afterwards I followed the steps to reset the runner registration tokens.
Finally I deleted al the instance variables in the dbconsole, by deleting them out of the database.
Check first if this is similar to gitlab-org/gitlab issue 218913 which includes two possible root causes:
Either you have an adblocker on, which could affect that functionality
Or:
go to the project settings general -> Visibility, project features, permissions
In Pipelines (Build, test, and deploy your changes) select Only Project Members
I had the same issus after restore a backup :
My solution was to delete variables from the database :
sudo gitlab-rails dbconsole --database main
gitlabhq_production=>delete from ci_instance_variables;
gitlabhq_production=>delete from ci_variables;
then it works
When creating a second migration and attempting to migrate up to add it, the task fails because the first migration was already run. It seems to be running (and failing) rather than skipping previously successful/complete migrations.
I have tried with --no-check-order but I don't want to do that everytime I got new migrations to add.
I have my database locally.
Using node-pg-migrate and postgreSQL
In a general way, the order of migrations matters as you can e.g. alter the same type and the last run migration wins.
It can happen e.g. if you have pull requests and merge them to base branch in a different order than the migrations were created.
You can now e.g. rename migration so it is sorted on disk in the correct order (before not-run-migrations) and update records in pgmigrations table, or you can put new migrations aside (so they do not trigger this error) and run as many down migrations as needed, then restore migrations definitions on disk and run up migrations.
So basically, I have Node.js application locally (WebStorm project) and constantly pushing changes to git. I would like to create one-click desployment solution executable from my WebStorm project what will:
Clone/Pull project from git
Install dependencies
Edit config (database connection, etc...)
Based on config make sure database is ready and if not initialize new one
I achieved parts 1 and 2 by using pm2 deployment function. If I run command, everything is updated from git and dependencies are installed.
Part 3 is problem, because I do not want to push production config into git (even it is private repo) and I have only example config in git repo. I was thinking about script what will copy example config and then prompt me somehow to edit it, but I am not sure now to achieve this without connecting manually into production server and second problem is I need to copy new example config every new version, because there might be changes in config structure between versions.
Any suggestions how to achieve this easily and without need to log into production server manually?
Part 4 is nice to have feature if anyone have suggestions how to achieve this, too.
A while back I generated a project with JHipster Registry, among other things (let's call it conf1). After a few months I realized I don't need it and changed everything I need to so my project would work properly (this one will be conf2) and it work as expected.
Now, every time I want to upgrade my project, JHipster generates everything based on config1 instead of config2, which means my changes to get rid of anything I don't want, for instance JHipster Registry, get overridden by the upgrade.
So my question is: what do I need to change so that every time I upgrade to a new JHipster version, I don't get it done based on config1?
Deleting the jhipster_upgrade branch solved the issue.
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.