Staticman: Unable to host own instance

[alexwaibel]

Mostly just making this to point other issues to and to formally document the current issues with the repo.

The current master and dev branches appear to build with minimal configuration of a simple github token and a private key though tests fail to start on either branch.

I'm working on fixing this and further testing and documenting the APi but in the meantime there remain various hosted instances which may or may not be working and that I won't link to as I haven't had time to verify any of them to be working myself.

[alexwaibel]

Have made some progress in this regard. Cross posting from another thread:

For now, I have been able to get this working on a test instance. For the best results, I would recommend hosting your own instance of my patched dev branch. I would recommend only using personal access token authentication with GitHub as well as /v2/ of the Staticman endpoints and not /v3/ for now, as I haven't gotten to testing the rest yet. You can quite easily host your instance in Heroku. The abridged version is:

1. Fork my dev branch to your own repo
2. Create a free Heroku account and link to your GitHub
3. Create a new Heroku app and select the options to deploy from GitHub then select your fork repo
4. Create a new GitHub account to run your bot. In this account, generate a personal access token in dev settings and use this in your Heroku config for your own Staticman instance.
5. In Heroku settings for your deployed app, set your config vars using these API config options
6. Follow this guide but using your own API on Heroku instead of the public staticman instance.

Best of luck. Let me know if you need any further help and I'll do my best to point you in the right direction.

[alexwaibel]

Alright, this has been resolved with #319. Users should now be able to run their own server on any infrastructure of their choosing. Additionally, the above Heroku deployment steps have been simplified and users can simply click the "Deploy to Heroku" button in the README rather than forking the repo and deploying everything manually.

[travisdowns]

For the best results, I would recommend hosting your own instance of my patched dev branch.

@alexwaibel - is this part still true, or has this been merged to upstream (i.e., this, eduardoboucas, repo)?

Thanks in advance, I'm just getting started on this journey and hope to produce some useable documentation for the "as of today" approach to getting staticman running on Heroku.

[alexwaibel]

@travisdowns I would now recommend forking the dev branch of this (eduardoboucas) repo. Master works fine, but the dev branch has a full suite of passing tests that I haven't gotten around to merging the fixes for into master yet. Best of luck and feel free to ask any follow up questions you might have here.

[travisdowns]

@alexwaibel - thanks for the speedy reply! I'll probably stick to master, partly because...

I've already used the "deploy to heroku" button the readme, which has presumably deployed _this_ repo, not a fork. Is that a problem? I assume that all the me-specific config can be done in Heroku, or is there some advantage to making my own fork? I guess it gives me control over keeping up with changes?

[alexwaibel]

@travisdowns to clarify, using the deploy to heroku button you do not need to make your own fork. The button when viewing master should deploy this repos master branch. If you switch to viewing the README of the dev branch and click the button there, it should deploy the code from this repos dev branch. In any case, all configuration will be done by setting the configuration variables in heroku. Hope this helps clear things up.

[travisdowns]

@alexwaibel - thanks, if you are still willing, here's my next question:

I need to create and update the config.production.json file in the Heroku deployment to configure my instance of the API. I am not a heroku expert, but it seems like this wont' be possible if the deployment is linked to eduardoboucas repo. I could fork the repo to get around this. Is there another way to get around this?

Second, I guess it is obviously wrong to include things like my github personal access token in a public repo: is the suggestion to make the repo private or is there a way to store this info in a heroku-specific safe way?

[travisdowns]

Also can you briefly explain the purpose of the github private access token (presumably allowing access to send the pulll requests), and the ssh private key (not clear)?

[alexwaibel]

@travisdowns you're correct about the GitHub access token, that is the personal access token which allows GitHub to make PRs etc on your repo. The SSH private key allows some fields to be encrypted before being sent in the comment creation request, though to be honest I'm less familiar with this functionality.

[travisdowns]

@alexwaibel - thanks.

I am still thinking about the secrets. In issue #311 there is some implication that Heroku env vars can be used at least for the private key, but the rest of the discussion diverges and so I am left uncertain how to deploy these secrets.

[travisdowns]

@alexwaibel - actually #315 makes a better reference as it was started by someone you might know :) and it mentions GITHUB_TOKEN and RSA_PRIVATE_KEY so it seems like you also may know about the env vars. Did you get it working? Are these the right vars?

[alexwaibel]

@travisdowns Not sure I understand your question, but to add a private key to a server deployed on heroku, you add a config variable with key RSA_PRIVATE_KEY and the value being the text of the PEM key. Be sure to replace any newline characters with 'n' as the key string should be all on one line. All other config variables can be set in heroku in a similar manner.

[travisdowns]

@alexwaibel - my question is that the node.js app that implements staticman needs a config.${NODE_ENV}.json file configured, correct? For a Heroku deploy, ${NODE_ENV} will be production, right?

So I will copy say the existing config.sample.json file and then I will add secrets to this file, such as githubToken and rsaPrivateKey, correct?

How is this possible in the context of a Heroku dyno deployed from this repo? I can't add that file to this repo. Even if I add that file to my fork on github, it would be exposed.

The usual way to add secrets to a Heroku deployed via github is via "config vars" which are really environment vars. Your #315 suggests this is possible, since you talk about adding heroku config vars with very similar names to those mentioned in the config.*.json file, but I am not sure if they are the same.

[alexwaibel]

@travisdowns in the case of a Heroku deployed instance, you do not need a config.*.json file and instead these config values are set using "config vars" aka environment variables.

[travisdowns]

@travisdowns in the case of a Heroku deployed instance, you do not need a config.*.json file and instead these config values are set using "config vars" aka environment variables.

Well thanks, that's what I was missing!

[travisdowns]

Even though I looked at this page a couple times, I never picked up on that - but it is in fact documented there...

[travisdowns]

Thanks @alexwaibel - I got it all working and wrote up the process here. Maybe it can be of use to someone else.

I found a couple of issues in the error handling and submitted PRs for them.

[alexwaibel]

@travisdowns thank you for your contributions! It may take me some time to review those PRs as I've gotten busy with finishing up school. I'll definitely take a look when I can though.