I'm using Firebase Hosting for hosting a web app. I'm also hosting some small screencasts on the site, however every time I want to make a change to the app and deploy, I have to wait for the videos to be pushed.
Is there a way to selectively push changes to Firebase? Also, why does Firebase not simply push new/changed/touched files? I assume because its not doing any revision control for hosted applications and therefore isn't tracking such things, but that just makes the selective push much more of a need.
Currently, Firebase is not performing any sort of revision control, so automatic ignoring of files that haven't been changed/touched is not an option. However, in firebase.json, one can specify files to ignore in the .ignore section.
I had been looking for more of a manual option to specify in the command line when performing a firebase deploy, but performing it in the firebase.json file probably makes more sense if one knows the file has not been changed or does not need re-deploying.
https://www.firebase.com/docs/hosting/guide/deploying.html
From the docs:
ignore
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
]
optional - The ignore setting is an optional parameter since v1.0.1 of firebase-tools that specifies files to ignore on deploy. It can take glob definitions the same way Git handles .gitignore.
I'm using WebStorm...I could never get the backgrounds or images in a gallery to upload or change...what I did was rename the files and have WebStorm refactor it...once I did that, gulp build and then firebase deploy seemed to fix it for me...I know it's a tad of a work-around, but this is silly it just won't push changes
Related
I am very confused about how this all works, so I am gonna make a series of questions.
So I am almost at the end of my final degree project and I have been using Github for version control. At some point, I had to store large files (>100mb) and got this message:
My first question is: what does actually happen if I click "commit anyway"? does it mean that I can't commit anymore?
Anyway, I have done research about lfs and eventually installed it in my repo (btw, this is a Unity project). I have followed this video: https://www.youtube.com/watch?v=09McJ2NL7YM&t=615s. This guy suggests using this custom .gitattribute: https://gist.github.com/nemotoo/b8a1c3a0f1225bb9231979f389fd4f3. This automatically tracks all files with a certain extension and pushes them in lfs. At the time I thought this was cool, until I realised that this file made me push all tracked files no matter how big or small they are. what I should have done is use bash for pushing to lfs only when I would get the message above (so only for files >100mb). Since my whole degree depends on this project, I did not want to mess with GitHub and spend time trying to "fix it", but I want to know if there is any way to restore the whole history and made it as I have never used lfs (?)
Lastly, since I got loads of files stored in lfs, I get that whenever someone re-clones my repo, can just do git lfs fetch --all and then git lfs pull (and this should use up my bandwidth, right?). But.. what happens if someone decides to just "download" the project ("download zip)? Well, I have tried it, and all those files are missing completely.. Is there a way to download the project with the original files instead of pointers?
Also, if you exceed the free 1gb data pack that GitHub provides, and stop paying for additional storage, do you lose all those files??
At some point in the future, I would like to remove lfs, and if I have to, only store files >100mb (I think they are just 2 in total). But would that still mean that to have a complete version of the project the only option would be to clone the repo instead of downloading (?).
Sorry for the long question but I really need to understand these things.
Refresh NetSuite sandbox from production (code only)
I realize that we can refresh out sandbox from production but we don't want to refresh the entire sandbox, instead we want to refresh NetSuite SuiteScript, NetSuite Forms & UI Objects.
NetSuite's proprietary infrastructure/code and challenge it brings
I resisted asking this question for several weeks thinking it was too basic but it doesn't appear that way. After working with NetSuite for a while it has become clear that the line between source code and data has become blurry and it's my opinion this is exactly what makes refreshing code challenging.
I've also learned that storing NetSuite code in version control software is next to impossible (for all code) and this leads me to believe that my desire to refresh code only might be impossible as well. I have to wonder how IT shops that are encumbered by SOX compliance issues are able to satisfy auditors when it comes to controlling and modifying the business logic.
The real question and reason for refreshing the sandbox code
My motivation for refreshing sandbox code is the fact that we are encountering unexpected behavior in our sandbox accounts with certain forms (invoice & estimate) where custom tax fields (Ava-Tax) mysteriously moved from the items tab to a tab that contains transaction body fields! The form appears to not have been updated by anyone in over a year and there were no packages installed in the sandbox that might have broken the form.
If I cannot refresh source code is there a way to determine how a NetSuite form became corrupted knowing that the NetSuite Form is stored in a proprietary way and with no apparent source code available? I understand most of the NetSuite code is JavaScript that runs on both the server and client and there are parts that are unavailable to anyone outside of NetSuite.
Any solutions or suggestions are welcome and appreciated.
It is not at all impossible to store NetSuite code in Source Control. We use git to track all of our NetSuite source, and we follow a process similar to gitflow. Our master branch is always kept in sync with Production. Anytime we push code to Production, that gets merged from its feature/fix branch up to master and tagged as a release. If we want to roll back, we just revert master back a commit and upload the whole project to the File Cabinet. Then, if we want to refresh a Sandbox to match Production, we simply checkout master and upload all of that to the Sandbox.
Sandboxes themselves are much more difficult to keep in sync with a single branch in source because we are constantly developing there on separate feature branches.
If you do not already have such a system in place, all you really need to do is download the zip of your SuiteScripts folder from the Production File Cabinet and upload that to your Sandbox.
This isn't source control, but you can use SuiteBundler to copy items between accounts. SuiteBundler allows you to choose from a lot of things like forms, scripts and custom records. Later you can uninstall the bundle or dissolve it into the account.
It's not so easy to explain in few words, here but: You can use a deployment account to get things work properly. So you continuosly work on dev accounts and use multiple bundle / bundle version for follow branches/Versions of customizations. You update bundle from dev to deploy account only when a version is stable and production envs always install / update bundle version from deploy (not from dev). Since bundles are versionable and infinite, you can use git + dev + deploy account for manage Cvs. For get a versionable version of a form just add &xml=t in url in any form. But this is read only
I have a dev folder with all my projects. Some of these are on github and some are not. I also use Dropbox (with symlinks) to keep my data synchronised across several computers.
For example if I add something to my Documents folder on one PC I can then see it in the corresponding folder on another PC.
My question is: If I do the same with my dev folder (so the dev folder is synced by Dropbox on both PCs) will it cause problems with my pushing to github?
You don't ever want to mix code versioning strategies. Either all of your code lives in git (which is a good idea), or it all lives in Dropbox (which doesn't give you any history, hence a very bad idea).
When you add a source file to git, you should be forced to push it to Github so it can be pulled at a later date.
I get the feeling that you will run into issues when pushing the code - you'll be adding new files in through one source, but pulling through another - it'd turn into a headache more than a benefit.
I'm not sure exactly how you could "prove" that is ok. But, I have used exactly this development model with no issues. I personally, don't use symlinks in my dropbox but that shouldn't affect anything. All of my git repos are on my Dropbox. I've been working this way for over a year across OXS, Windows, and Ubuntu. All of my commits and pushes have worked just fine.
Also, this may be a repeat of this question: Using Git and Dropbox together effectively?
[edit:]
Actually one thing was recently brought to my attention is that you might run into an issue with line endings across systems. This post from GitHub (with a link back to an SO question) explains how to deal with line endings.
I had the same question and now my answer is "simply move your repository out of Dropbox".
As you can see, Using Git and Dropbox together effectively? is not the same question, but if you just search the key word "GitHub", you will see the debate about your confusing. And maybe you will make your own desition.
The situation:
I have a basic app with some central functionality.
My clients (potentially many dozens) all want their own customized apps in the app store.
The problem
If I have dozens of apps in the app store and I want to change some of the core functionality, I would have to update each file in the corresponding project, compile, go through iTunes Connect, upload etc. Every small change could potentially take days of mindless work.
The question
Is there a way I can use a versioning system like git to administer the parts of my code with the core functionality separately, so that all projects are updated automatically when I commit a change to the core files?
Is there any other way to make this process easier to manage?
Typically if you have some core functionality that you need to reuse in iOS you'll either create a static library that you can include in your other projects or (if the core functionality includes things like assets which can't be included in a static library) you'll have a sub-project. In both cases, though, you'll want to make sure each of your app projects has a target dependency with your core functionality project so it is always rebuilt with the latest changes.
Create a MundiCoreFramework xcode project that has all your core functionality and which compiles without having to reference client-specific code
Create a git repo for this core framework project
In each of your app projects that use this core functionality, add the MundiCoreFramework as a git submodule and add it as a subproject to the app project.
Whenever you update the core framework you can issues git sumodule update for each app and recompile.
I'm not real familiar with the Xcode "target" structure, so that may in fact be a better approach. But you can definitely use git for this.
Probably you want a "master" branch where all the universal stuff lives, then a branch for each "customized" version of the app.
When there are changes in the master, you'll merge those changes through each of the custom branches. Then from each branch, you'll build a product to submit to the store.
In each branch, you'll separately set the app id, whatever art and text changes are needed from one version to the next, whatever key setup is appropriate to this version, etc. All those settings can stay local to the custom version branch.
This is a perfectly valid workflow in git. It's not how most people use it, but that's because most people are headed to ONE production product, not many.
Another option might be using git submodules to organize common code, and then have each individual project simply add your common code as a submodule.
You can use Target to customize the app for each client, this would mean that you could keep one code base and have multiple apps with the same code base.
This will not solve the updating the app in the appstore part, which you would still have to do by hand as var as I'm aware of.
I just started using github.com and my friend and I are working on a project. How can I pull parts of the project but check out certain files I'm working on so he doesn't work on them. He can still download the files but he won't be able to open or edit them until I upload them back and give permission?
I suppose you mean lock a file when you edit it. Git won't let you do this and it's not something you need to worry about. Instead, you can both work on the same file and then merge your changes later.
If you really want to work that way (i.e: lock files, or at least control when your friend will modify your repo), you can ask your friend to fork your repo.
That way, he/she:
will have his/her own copy of said repo
will work on any file
will rebase first with branches fetched from your repo (added as a remote on his/her fork, as described in GitHub: working with remotes)
will make pull request, allowing to decide what to include and when.
Historically version control systems provide a checkin/checkout feature. When you do a checkout, you reserve the artifact. If another person also has the same file checked out, then you get an error when trying to checkin the artifact. Not sure creating another fork is really the equivale