Pushed 1 change to painless-deploy
Woke up at 2:30am and squashed a few bugs in
Now going back to bed at 5am to get some sleep before office work.
env-exec script in cannot take env vars in the command line - because it is interpreted immediately
Fix it or convey that in the documentation.
Hint to self: Go check how asdf version manager does it. I've totally forgotten if I ever handled this in there.
Hint to self: Go check how asdf version manager does it. I've totally forgotten if I ever handled this in there.
Akash Manohar
Author
The most workable way seems to be to construct a release script inject the command to that script.
Add support for build command in static stack in This means an extra process won't be required for static sites
Pushed 1 change to demo-nodejs
Pushed 9 changes to painless-deploy
Used PageSpeed Insights to optimize the nginx config a bit for
The website for #PainlessDeploy is a rails app, which is also deployed by #PainlessDeloy. So I've been using that as he demo app for testing rails deployments.
In the process when optimizing the nginx config, I've also optimized the landing page for the project (or whatever remains). I'll stop here and move on to other tasks.
In the process when optimizing the nginx config, I've also optimized the landing page for the project (or whatever remains). I'll stop here and move on to other tasks.
Pushed 7 changes to website
Explored the internetz and figured out how to sell access to - GitHub/GitLab deploy keys
I expect use-cases with tools like CircleCI and GitHub Actions to deploy apps after test-suite passes.
If I host the pip package myself and if users do not cache package/dependency fetching, then I'll be drowned in recurring (monthly) bandwidth cost.
Creating GitHub/GitLab Deploy keys for each customer will help me offload the cost for recurring traffic. Got this idea after exploring the services that allow users to offer paid access to GitHub repo (Hat tip: GitStore).
If I host the pip package myself and if users do not cache package/dependency fetching, then I'll be drowned in recurring (monthly) bandwidth cost.
Creating GitHub/GitLab Deploy keys for each customer will help me offload the cost for recurring traffic. Got this idea after exploring the services that allow users to offer paid access to GitHub repo (Hat tip: GitStore).
Akash Manohar
Author
So the onboarding/setup is:
- painless-deploy as a pip package available for free - but that'll include just the python script that runs the setup and deployment scripts. I'll make this public.
Akash Manohar
Author
[Hit enter too early in the previous comment]
- The second part is the git repo with actual deployment scripts - which users can only access with the deploy SSH key created at the time of their purchase
This two-part distribution is intentional to avoid further steps in the onboarding. The python pip package has other python dependencies that will be pulled in automatically during install.
So the setup is going to be:
pip install painless
The below stuff will be copied from the site
by the user after purchase
(very rough. Just typing this out)
mkdir ~/.painless
echo "bla bla bla deploy key" > ~/.painless/key
GIT_SSH_COMMAND="ssh -i ~/.painless/key" git clone git@github.com:painlesstools/painless-deploy.git
Pushed 1 change to painless-tools
Pushed 1 change to demo-ruby
Worked on optimizing the setup for Rails apps for
Pushed 8 changes to painless-deploy
Pushed 8 changes to painless-tools
Pushed 2 changes to painless-tools
Pushed 6 changes to painless-deploy
Pushed 3 changes to painless-tools
Pushed 7 changes to painless-deploy
Pushed 2 changes to demo-nodejs
Pushed 4 changes to painless-tools
Pushed 2 changes to painless-deploy
Setup a rails app for the website
Spent 30 minutes wondering whether to use Rails or anything else. Realized it is better to stick to what I know will come batteries included for most things I need. Don't want a wild goose chase on stackoverflow for something I don't know. I'll optimize with a framework I know well (or atleast knew before).
Thanks to a video by a good soul on Youtube https://www.youtube.com/watch?v=3xcUSIu3nXA
I was able to add Tailwind to a Rails project.
In addition to that:
* I chose to stick to the previously done index.html static landing page.
* But Rails does not support using the assets generated via webpacker to be used in public/index.html
* And don't want to any requests to the landing page to go through the Rails app
So I've gone an extra mile to configure webpack to output a public/index.html that nginx can serve directly. This particular config trick definitely warrants a blog post. Marking it for sometime next week.
Thanks to a video by a good soul on Youtube https://www.youtube.com/watch?v=3xcUSIu3nXA
I was able to add Tailwind to a Rails project.
In addition to that:
* I chose to stick to the previously done index.html static landing page.
* But Rails does not support using the assets generated via webpacker to be used in public/index.html
* And don't want to any requests to the landing page to go through the Rails app
So I've gone an extra mile to configure webpack to output a public/index.html that nginx can serve directly. This particular config trick definitely warrants a blog post. Marking it for sometime next week.
Akash Manohar
Author
Hopefully I can complete this site in a few weeks. I still don't have screenshots and demo video given that certain other tasks are pending. Using the Tenet trailer video as a placeholder for now.
Pushed 15 changes to painless-tools
Began writing documentation for
While writing the docs, I was able notice that I can cut down scope even further for the MVP. Cutting down on the interface to create servers. Will only handle setup and deployment on release.
Added support for deploying React/Vue/static along-side other Python/Ruby/Node.js apps.
Best part: URL routing is handled too. So directly visiting a react route in the browser will render the react app appropriately