Guide to setting up a development install

[Guido1982]

I know I've asked this before in the gitter group, but I keep forgetting to note the steps. So this is meant as a note to self and others: what is the preferred approach for setting up a development installation?

[joebordes]

there is really no difference, you simply "git clone" your repository, install and develop
that said, this is what I do when I work on a new project.

1.- create a repository (private or public) for the new project
2.- clone the repository
3.- add a remote to coreBOS:  git remote add corebos https://....  (wherever your base coreBOS lives)
4.- merge the corebos base into my empty repository: git pull corebos master
5.- git push to save the changes into the local project repository (the first time you have to add the -u parameter)
6.- install coreBOS normally
7.- recover the install and Migration directories that have been renamed for security and either remove them if you will never need them again or simply leave them there if you do need them
8.- I usually ignore the config.inc.php and any other file that has been modified
9.- optionally you can add a config-dev.inc.php file to modify config.inc.php variables

from then on you can have two situations

you make a change which really belongs in your base project (corebos above). In that case, you make the change there and launch a git pull in your project

you make a change which is only for your project, you commit it and continue

obviously, from time to time, you must pull/merge the changes that happen in the base coreBOS project.

Keep asking

[Guido1982]

What do you do with all the files in the migration folder after the install completes? Git tracks them as deleted.

[joebordes]

I updated step 7 in the instructions above. I had written merge instead of Migration.

The idea is that once you have finished the install you recover the install and Migration directories and the install.php file. That way, git doesn't complain and you have them in place in case you need to modify them.

If you are never going to install again you can delete them and commit that change to your private repository.

Also, instead of installing in step 6 you can use the test database which has data.

[Guido1982]

Ah, I understand now: should place the Migration folder BACK into the modules folder. That got rid of a lot of red git status lines..

[opto]

>you make a change which is only for your project, you commit it and continue

... should't I put that in another branch than master (local) - like a branch dev_local?

otherwise, if I do changes like:
change 1 (global)
change 2 (local only, no general interest to public)
change3 (globl)

and send a pull request, my local change will be in that pull request as well?

I think I would keep my local master in sync with upstream master and occasionally merge that into my local branch dev_local.
Locally, I would deploy from dev_local. Now I can insert code totally unrelated to global corebos development.

Or am I wrong in this?

[joebordes]

You are absolutely right.

I apologize, I was thinking of a private repository that syncs with coreBOS. The way that works is that each project has its own repository which merged from the coreBOS project, in that repository you can commit your changes directly to the master branch and pull in all the changes in coreBOS as you need them. If you need to get some change into the main coreBOS project you must do it using branches as you explain.

Thanks!!

[Guido1982]

I just read this again and for the first time it dawned on me that you aren't talking about developing in your main fork. What you are talking about is:

• Tsolucio corebos main project
  • My fork, that I use to keep in sync
    • My development install that I use to develop some new feature in
      
  
  

I could then create a PR to my own fork (can I merge that into a branch on my fork?) and create a PR from the fork into the main coreBOS project. In case I want to develop something that I believe should be in the main project, that is.

[joebordes]

Yes, that is more or less correct. The only thing is that you have direct access to your repository so you don't have to make a PR there, you can merge branches directly without the need of a PR.