I have an Odoo instance (13) installed from GitHub reps and want to update to version 14.
I followed the steps here 1:
Enter the odoo base code in /opt/odoo/odoo
git fetch
git rebase --autostash
Then i updated the modules starting the service with the options "-u all -d mydatabase"
su odoo -c "/opt/odoo/venv/bin/python3 /opt/odoo/odoo/odoo-bin -c /etc/odoo-file.conf -u all -d mydatabase"
After a while, when the process finished the Odoo version is still 13.
There's no customizations in code and database, and there's no true records there.
I would like to know if there's a step i missed or the correct way to update Odoo.
Thanks
First git branch to see what is actually checked out.
If you are using self hosted community edition of Odoo then you have to do manual data migration before the upgrade.
Backup everything and start with test environment. It will go wrong.
You have to know what data is in your database. And what changes are made to the Odoo.
there are tools and tips but not yet for ver 14
https://github.com/OCA/OpenUpgrade
Related
I'm following Odoo 10 Development Essentials Chapter 2 to develop a simple todo addon. I'm using odoo's docker as my environment.
You can check all my source code (including dockers') at https://github.com/spacegoing/docker_odoo
The problem is I set up my tests/ directory exactly the same as the book's example. However, the test only run once. After the first execution the test was never invoked. There is even no .pyc file in tests directory.
Here are the commands I tried
odoo --db_host db --db_port 5432 -r odoo -w odoo -i todo_app --test-enable --xmlrpc-port=8070 --logfile=/var/log/odoo/odoo_inst1.log
odoo --db_host db --db_port 5432 -r odoo -w odoo -u todo_app --test-enable --xmlrpc-port=8070 --logfile=/var/log/odoo/odoo_inst1.log
Notes:
odoo-bin is odoo in docker
I've installed todo_app with another odoo instance running on port 8069
Finally I found the answer. This is the hugest gotcha I've ever met since I'm 5 years old.
No where mentioned in official document that test will only run after you installed the demo database.
I found this from this forum post:
https://www.odoo.com/forum/help-1/question/why-my-test-yaml-do-not-run-42123
So if you tried every single command you can find and none of them works, this might be your answer.
I've just cloned the RC0 of PrestaShop 1.7.
I've run composer install but... what to do now?
I've tried to start the server with app/console server:start but, going to 127.0.0.1:8000 i receive this error:
Front not yet implemented! Or to delete...
So, this seems not to be right way:
app/console server:stop
and try another way...
Go with the classic localhost:
Link to database cannot be established: SQLSTATE[HY000] [1049] Unknown
database 'dev-prestashop-1_7'
Ok, I've to create the database... Database dev-prestashop-1_7 created... Try again...
Table 'dev-prestashop-1_7.ps_shop_url' doesn't exist
Yes, it's normal that it doesn't exists: I've not yet created it!
But, now comes the question: how I configure PrestaShop?
How can I start the installation procedure using the composer version of PrestaShop 1.7 RC0?
Once you have downloaded the zip of prestashop, you have to unzip it in a specified repo and give it the needed permissions. Then, you acces to this repo in a chosen browser.
For example (if you are under Linux system), let's say that your repo is called prestashop_1.7 and is put in /var/html/www, so you access to localhost/prestashop_1.7.
When accessing to this URL, un install unzipper will start and when finishing unzipping, it will lead you to the installation configuration.
You enter your configuration (you have to create the database manually) and that's it!
Is it possible to delete old builds in Gitlab CI?
I tested a few things and have now about 20 builds that are useless (most are failed anyway).
It also shows stages that I don't have anymore which kinda clutters the Pipelines page and some of the uploaded artifacts are a bit big.
I wasn't able to find any documentation on this, only that disabling CI in the settings doesn't remove the builds.
Using Gitlab 8.10 Community (hosted by Gitlab.com)
There is currently no option in the GUI to completely get rid of a build other than expunge related data from the build. (The erase option in the build)
If you would have a local installation you could modify the database directly but I would advise caution. (I'll put the guide here for completeness sake)
Login to the GitLab database. If you use the default PostgreSQL :
sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
Check if there is a table ci_builds. For pSQL: \dt
Delete the builds with normal SQL. For example: DELETE FROM ci_builds WHERE id = 2
(Optional) If you want to cleanup a list of commits which triggered a build you need to midify the table ci_commits.
I follow the installation guide at http://golang.org/doc/install.html,
at first everything goes well, but problem comes at the "fetch the repository" step,
the guide says "$ hg clone -u release https://go.googlecode.com/hg/ go"
I follow the command but system always say that's wrong
so I read the help and modified it into
"$ hg clone -U release ..repo url... go"
(I don't see a lowercase u option but there's a U instead which means noupdate)
but still goes wrong
so I modified it again
"$ hg clone -U r60 ..repo url... go"
(I think release actually means go release number?)
ok, now that works finally
but, when it's over
cd to the go directory,hey,why all the files are hidden?!
and different with the url directory, for ex there's no such a src directory
so what am I doing wrong, and sorry for my english is not good
thank you for your help
for as a new user I can't attach a image and can't have more than two links in one post, see the picture link below at the reply to Evan Shaw
and in the guide page they say that I need to install python-setuptools python-dev and build-essential, because in ubuntu/debian users' distribution's package repository, the will "most likely be old and broken", what that mean? Am I suppose to install the tool manually(but not a easy_install)?
for a new user I can't answer myself,I think jnml points out the best matched answer
I thought this question is answerd,
the problem is that repository in Ubuntu/Debian for is tool old,
if you just easy_install (apt-get install )
you got version 1.0.1 , that's not match for the command gave on the go installation guide,
so a simple way to work it out is(thanks jnml for pointing this out):
hg clone
cd go
hg update release
that's done.
but I still wonder how can I get the latest version of be installed on my Debian,but that's another question,
Thanks a lot to all of you who reply to me, thank you for your help!
hg -u (lower case) is definitely correct, check your version of mercurial.
$ hg help clone
...
options:
-U --noupdate the clone will include an empty working copy (only a repository)
-u --updaterev REV revision, tag or branch to check out
...
$
I'm using rvmrc with the following text:
rvm_path=/local/rvm
(on Ubuntu 11.10) but trying to install gives an obscure error:
$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
Successfully checked out branch ''
Current branch master is up to date.
Successfully pulled (rebased) from origin
: No such file or directory
Any ideas?
You have no need at all to set $rvm_path. You're using a multi-user install. Please follow the explicit instructions for the Multi-User install at https://rvm.io and remove any existing installations, remove /etc/rvmrc, /etc/profile.d/rvm.sh, and $HOME/.rvmrc. Comment out any RVM sourcing lines in your .bash_profile, and .bashrc and log out of the machine then back in. Then reinstall correctly. Setting the rvm_path has never been a requirement of the installer UNLESS you already have a Multi-User working installation in place, and you want to attempt to use a per-user install with it. THEN you would preset the $rvm_path to $HOME/.rvm in your own $HOME/.rvmrc, log out then back in and then attempt the install again. BUT, that is not a supported installation type. Which is why 99.999% of users will not need to set rvm_path at all.
The real problem was that the git configuration for auto-converting line endings was not set correctly which prevented any installation from working. It had nothing to do with using rvmrc settings.
The fix for this is simple (and comes straight from the github help page):
$ git config --global core.autocrlf input
Line endings are important in linux and by forgetting that setting, everything the rvm-install script was pulling from github had \r\n endings. I made that change so long ago on my work machine, I didn't even remember it -- but it was not set on my home system.
I'll leave it up in case someone else has the same problem.