I followed the instructions at https://create-react-app.dev/docs/deployment/#github-pages and noticed that the command gh-pages -b master -d build replaced the contents of my working directory with the contents of the build folder and committed these changes to the master branch. This works as advertised to publish my React app at myusername.github.io, but it makes it impossible to make further changes to the source files since they are no longer available in the working directory.
I understand that GitHub project pages work differently than GitHub user pages (they allow the application to be published from the gh-pages branch rather than master). So, do I have to move my code to a new project repository or is there a way to accomplish the same thing using my existing user repository?
You can maintain your repositories code on the master branch by changing the repository settings on Github, for Github Pages, use the /root directory and select a new branch other than master, then, also change your deploy script.
Optionally, for a custom domain built using create-react-app, you will need to and a CNAME file to the your apps public directory.
Github Pages Settings:
Github Pages settings using branch named production
Add optional CNAME file:
Add CNAME file to public directory for custom domain
Change the script to point to the new branch. In your package.json file update master to the name of your new branch.
Change:
"deploy": "gh-pages -b master -d build",
to:
"deploy": "gh-pages -b production -d build",
Where production is the name of your new branch.
There's no need to move the code. Simply create a new branch called source (or dev, or whatever you want to call it) from the commit just before gh-pages' first "Update" commit, and use that branch, rather than master, to continue development.
Related
I tried uploading my files to Github, but GitHub says it's too big.
I then uploaded the content of the dist folder after building for production.
This worked just fine, but it's not very useful.
What is the proper way to upload a Vue.js app to GitHub?
What you generate (binary files which can be big) should not be versioned/pushed to GitHub.
It is better to use a local plugin which will, on GitHub side, build, tag and publish a release associated to your project.
For instance: semantic-release/github.
You can combine that with a GitHub Action, which can take that release, and deploy it on a remote server of your choice (provided it is publicly accessible from GitHub): see for example "How to deploy your VueJS using Github Actions (on Firebase Hosting)" from John Kilonzi.
For your existing dist, you should delete it (from Git only, not your disk) and add it to your .gitignore:
cd /path/to/repo
git rm --cached dist
echo dist/>>.gitignore
git add .gitignore
git commit -m "Delete and ignore dist/"
git push
What happens if I add a node module( like if I decide to add an image cropper). How can the other contributers deal with that?
You need to add the declaration of that module in your project, not version the module itself. For instance, using Vue.use.
Also: I host the app on netlify. It builds the site straight from github. But it wont be able to build the site if gihub doesnt have the dist folder...
See "How to deploy your Vue app with Netlify in less than 2 min!" from Jean-Philippe Fong: Netlify itself will build the dist (from your GitHub project sources) and publish it.
You should add a .gitignore file to the root of your directory where you can ignore files and directories.
Most typical ones to ignore are the following:
node_modules
/dist
.env
.vscode
I am running Odoo 13. I created a new staging branch and used the Odoo.sh web editor to make changes to primary_variables.scss (/src/odoo/addons/web/static/src/scss/primary_variables.scss). However I can't figure out how to commit these changes and push them to my staging branch and merge with the production branch. If I navigate to /src/user and git branch -r I can see all my staging branches however if I navigate to /src/odoo and run git branch -r I can see two branches origin/HEAD and origin/13.0. What am I doing wrong?
No, you can't do that.
Your instance is made up of 4 git repositories. /src/odoo is from https://github.com/odoo/odoo You can change only /src/user
You have to write your own module. That overwrites some CSS values or replaces it fully.
The next link speaks how to load your CSS file. I think you can load your modified file. As it is loaded later the original then it should overwrite original CSS.
https://www.odoo.com/documentation/13.0/reference/javascript_reference.html#assets-management
I'm new to JavaFX 8 and the IntelliJ IDE. I have a JavaFX8 project that works but not as I would like. I'd like to try another approach but the substantial changes may not work. I don't want to loose code I have working.
To save code I have working, I've been creating a new project and then locally copying all the folders(.idea, out, src) and files except .iml, of the working project into the appropriate folders in the new project with the newly generated .iml.
This always seems to work but is it proper procedure?
I'm not on a team of developers and have yet to learn Git/GitHub.
Please advise. Thanks.
Maybe you should learn how to use a Version Control System like Git, then you can create a project repository and have different branches for things you want to try out. Keeping the working code in your master branch will prevent you loosing your working code. Also, when using a vcs you can always revert to versions of your code that have been working. The IntelliJ Idea IDE has perfect support for working with all different types of version control systems. If you don't want to learn any forms of vcs then there is no other way to "backup" your working code.
Is it proper procedure? It's probably not how most people would go about achieving what you want to achieve but it's certainly workable. If you wanted to stick with that for simplicity now, I'd copy the whole directory structure, delete the .idea and .iml files, and then create a new project in IntelliJ on that clean copy: IntelliJ will automatically set up folder structure based on the existing source without you having to go through any additional manual setup.
If you're willing to experiment with the git route, to achieve the basics of what you want to achieve is not very complicated and I've written a small quick-start below. IntelliJ offers very good support for Git, and once your repository is created you can do everything you need from the IDE. I'm going to assume you're working on Windows, although the steps shouldn't be too far removed on other platforms.
Install Git
You can download and install Git from https://git-scm.com/download/win, which will install a command shell called Git Bash.
One-off setup for your project
Open up git bash and go into the directory containing your source. Rather than seeing separate drives as Windows does, Git Bash assumes there is a logical 'root' directory under which all your files are accessible. Your C: drive will be /c. To move around you can use cd to change directory (using / instead of ) and ls to list files instead of using dir.
Assuming your source code is in C:\projects\myproject:
cd /c/projects/myproject
git init
The second line above creates a git repository in that directory. This doesn't affect your code, it just creates a folder called .git that contains all of the book-keeping information.
You don't want to have every file under version control - in particular you don't want your build outputs. You need to set up a file in your project directory called .gitignore which tells git which files and directories should be ignored. As a starting point you can copy https://github.com/github/gitignore/blob/master/Java.gitignore and rename the file to .gitignore
Basic Commands and committing your initial version
There are a small number of basic commands:
git status
Running git status will tell you which files have been modified, which are not under version control, and which files have been added to the staging area to be committed next time.
git add path/to/file
This adds a file to the staging area waiting to be committed. You can add multiple files to the staging area before committing them in one go.
git commit -m "description of your change"
This commits all of the staged files as a new version, which the specified commit message.
If you go into your project directory, do a git status and check through the list to make sure there's nothing you don't want to have under version control, then you can do git add . to add everything to the staging area and git commit -m "Check in initial version of the source code" to commit it to the repository.
After you've committed, you can run
git log
To see a history of all of the changes. IntelliJ has a view that will show you the same thing.
Creating an experimental branch
This is where git shines; if you want to try something experimental you can create a branch of your project while allowing git to preserve the original version.
git checkout -b experiment1
Will create and switch to a branch called experiment1. You can delete, rename, move, rewrite and develop whatever you like on this branch. The changes you commit will be independent of your original working version.
You can switch back to your original version (preserving all of the changes you've committed on that branch) using:
git checkout master
Where master is just the name of the default branch created when you ran git init. The experimental version will still be there and can be switched to again using git checkout experiment1 or from IntelliJ using the branch selection in the bottom right corner of the status bar.
If you decide that the changes you've made in experiment1 are to become your new "good" version, you can merge them back into the master branch and repeat the cycle from there.
we are migrating from Gerrit Code Review to GitLab in our office. I know how to clone one repository from Gerrit to GitLab. But in our office server we have around 50 or so repositories. I have tried transferring the repositories manually to GitLab's 'repositories' directory and then importing, but it only creates bare repositories. I'd like to know if there's a way to clone all the repositories in one go. Please help...
but it only creates bare repositories
That is what GitLab manages, as a Git Hosting service: bare repos that you can clone locally.
You could move those non-bare repo by:
moving only the .git of your existing repo to GitLab repo folder, where each .git is renamed after the repo it was in:
repo1/.git => /home/git/repositories/repo1.git
repo2/.git => /home/git/repositories/repo2.git
repo2/.git => /home/git/repositories/repo3.git
If you are talking about two different servers (hopefully both with the same OS), I would recommend tar cpvf repo1.git.tar /tmp/repo1.git: move in /tmp and rename first, then tar, and copy over that tar to the new server.
transform those repos into bare one:
cd /tmp/repo1.git && git config --bool core.bare true
Try the Import process of GitLab (but there seems to be a bug in progress on that: issue/pull 5005
bundle exec rake gitlab:import:repos RAILS_ENV=production
While the import process command is correct, the OP redmoses mentions in the comments:
If I just copy the repositories to /home/git/repositories, then the repositories appear in GitLab with no source files or no record of previous commits done in Gerrit.
To make this work this is what I did:
Created a new directory inside the repositories directory
Copied all the repos from Gerrit (was located in /usr/local/gerrit2/git) to the new directory.
Then just simply ran GitLab's import process GitLab then created a group called "Dev" and imported the existing repositories perfectly.
And I didn't need to convert the repositories to bare.
Friends, I tried to deploy my yii production application from cloud9 IDE to OpenShift while do so, I got this error message,
CException
Application runtime path "/var/lib/openshift/51dd48794382ecfd530001e8/app-root/runtime/repo/php/protected/runtime" is not valid. Please make sure it is a directory writable by the Web server process.
Even when I changed folder permissions to 775 (chmod -R 775 directory) on Cloud9 IDE and deployed again, but I get the same error coming.
It's an old question, but I just bumped into the same issue very recently.
When you extracted the "yii" package several folders were empty, "framework/protected/runtime" was one of them.
To deploy to OpenShift you need to commit the yii package to git, and the push the commit to OS. But, git won't commit empty folders, so they are not created in your deployment. You need to create some file inside those folders and add those files to your git repo before committing/pushing. The usual procedure would be to add a ".gitkeep" file to those folders (it's just a empty dummy file, so git would see those folders).
That would fix this particular error.
It may be due the ownership given to the folder.
Check the web server user group, is that directory is writable or not and also What effects a web server when we change the platform.
Hope my suggestion would be useful.
For Yii applications, the assets and protected/runtime folders are special. First, both folders must exist and writable by the server (httpd) process. Second, these two folders contains temporary files, and should be ignored by git. If these temporary files got committed, deployment in plain servers (not Openshift servers) would cause git merge conflicts. So I put these two folders in .gitignore :
php/assets/
php/protected/runtime/
In my deployment, I add a shell script to be called by openshift, creating both folders under $OPENSHIFT_DATA_DIR and creating symbolic link to both of them in the application's folders. This is the content of the shell script (.openshift/action_hooks/deploy) which I adapted from here :
#!/bin/bash
if [ ! -d $OPENSHIFT_DATA_DIR/runtime ]; then
mkdir $OPENSHIFT_DATA_DIR/runtime
fi
# remove symlink if already exists, fix problem when with gears > 1 and nodes > 1
rm $OPENSHIFT_REPO_DIR/php/protected/runtime
ln -sf $OPENSHIFT_DATA_DIR/runtime $OPENSHIFT_REPO_DIR/php/protected/runtime
if [ ! -d $OPENSHIFT_DATA_DIR/assets ]; then
mkdir $OPENSHIFT_DATA_DIR/assets
fi
rm $OPENSHIFT_REPO_DIR/php/assets
ln -sf $OPENSHIFT_DATA_DIR/assets $OPENSHIFT_REPO_DIR/php/assets
The shell script ensures the temporary folders created on each gear after openshift deployment. By default, a new directory's right are u+rwx, and it became writable by the httpd process because the gear runs httpd as the gear user (not apache or something else).