rudimusmaximus
commented
6 years ago Manifest Files
Read more about these here
Current opinion
We will encourage you to include these in the gas GitHub assistant (manage manifests checkbox) when pushing back to the "truth branch" of your remote origin on GitHub (or other SCM). Just note it's an active space, and that clasp is exposing the manifest (appscript.json) to us which we had previously ignored what is usually hidden unless you use the view manifest menu option in the web editor. Just recall that advanced services and time zone will have to be set in each script's resource and file/project properties respectively; REGARDLESS of what your manifest says, there will be times you might have a cloned manifest that reflects this activity in another script 'life.' No matter, just make sure you enable what you are supposed to if you haven't which is pretty apparent in a new file.
Question In a Short Phrase
Gas GasGitHub assistant has issues with seeding a new script file. Is there another tool to create a new standalone script and push our local files to them? Yes, here is where 'Clasp' is at the moment.
Clasp
A work in progress, read answer carefully. As instructed, works well. Follow guidelines until Clasp matures.
Final Answer
Installing Casp
MacOS for now, do not use Homebrew for installing node (and it's package manager npm). If installed, from terminal remove:
A. Go HERE and download a pre-built installer for your platform
B. Install node (will install npm as well)
C. Go HERE and follow the code lab completing steps 1-5
NOTE. on step 2 use this command to install Clasp at a terminal:
Comments
Push works fine for us; however, pull will create extra/identical .js files for each .gs file that is in the script from which we are pulling AND leave the old .gs untouched (ouch!). Don't use pull. Well explain more below.
If you do by accident, you can delete these extra .js files, from a terminal in the top of your working folder for your repo:
Removes the .js files in the current and all subsequent folders.
To use within DevFlow and our "Make Test Ready" process
Scenario: I have a new feature branch and I'm working on a local cloned copy.
Assumes you have logged in using Clasp
1 Open terminal in your project folder yourPath/'DevFlow'
Run each of these three command lines one at a time. *Steps 2, 3, 4
On open, your last active browser window will open the script editor in a new tab. Note: once you do this in the same folder a hidden system file is created called .clasp.json it contains:
This is the standalone scriptID (active file) to push to on script.google.com, but don't ever pull using clasp. Should you need a new file later, just delete your local ".clasp.json" file and start again at the create step. That's it!
5 From there, follow the Rest of MakeTest Ready:
1 - enable advanced service Drive (and also in GCP console) (a future version of clasp will allow us to do this on the command line) 2 - with the START-HERE.gs file selected, make sure your semVer is what you want 3 - Run the makeTestReady() function by clicking on the debug run triangle in the menu bar of the web editor 4 - When complete, check the log and refresh your browser; if the function ran but the refresh doesn't show your new script name from makeTestReady, then use the name in the log and manually rename the script. Your new sheet has been created by the same name and your script has been renamed, but the change hasn't been detected yet. 5 - Continue with your testing 6 - Push changes back the appropriate origin branch (the diff should make sense to you) 7 - Use GitKraken to pull from your origin branch 8 - continue to work locally if you wish, use clasp Push to return to work in web editor after committing and pushing to your SCM truth repo.
IMPORTANT Notes and further research