I'm deploying my LoopBack project in Heroku using the buildpack in:
https://github.com/strongloop/strongloop-buildpacks.git
However I have a few changes I made to the LoopBack User model (specifically, I changed the ACLs to deny access to User creation by $everyone) and when I deploy it in Heroku those changes are overwritten with the default values (i.e. the ACL allows $everyone to POST to /Users)
My guess is that when deploying in Heroku, my changes are put first and then the buildpack is installed so any changes to the LB source code are overwritten.
Is there any way I can make changes to the LoopBack source code and deploy to Heroku?
Do I have to create my own buildpack with my changes? any recommended resources on how to create a buildpack?
Thanks!
After some research it seems that my assumtions on why this was failing were right. It turns out that the reason why the changes are being overwritten is indeed because the buildpack installs everything on top of whatever project structure you commit to your Heroku app.
In my case, since my changes involved changing StrongLoop's files, whenever the SL buildpack was installed those changes where lost.
Solution:
The way I solved this was by forking StrongLoop's buildpack and then adding a few lines to the bin/compile file to use sed to delete the ACL entries that allow anyone ("$everyone" role) to POST a new User instance:
status "Removing CREATE permissions for User model"
sed '42,47d' $build_dir/node_modules/loopback/common/models/user.json > $build_dir/node_modules/loopback/common/models/user.tmp
mv $build_dir/node_modules/loopback/common/models/user.tmp $build_dir/node_modules/loopback/common/models/user.json
(link to the position of the lines is here)
In the version of SL that I'm using this deletes the following lines:
},
{
"principalType": "ROLE",
"principalId": "$everyone",
"permission": "ALLOW",
"property": "login"
(link to GitHub lines here)
I then used this new buildpack to create a new Heroku app which now has disabled access to creating new Users by "$everyone" role.
Caveats
This is of course a very crude way of accomplishing this, and I would think that the correct way would be to actually fork the StrongLoop repo, make the changes there, and then use a buildpack that installs the forked repo, however in my case it meant that I had to be paying attention to fixes commited to the original StrongLoop repo and merge them back, which for the small change I needed seemed unnecessary.
Related
I'm currently using Heroku Pipeline feature for automatically detecting, building and deploying pull requests for review.
✓ Create new review apps for new pull requests automatically
URL pattern
Pattern: Random pipeline-xxxxxx-xxxxxx.herokuapp.com
The problem is that my app needs a combination of 2 buildpacks in a specific order in order to boot properly.
The main/production app has this settings and it works fine(e.g. after each time a PR is merged).
From what I see Review Apps doesn't have a concept of buildpack settings and it tries to autodetect it each time.
What I've tried:
Open the latest Review App, set buildpacks, rebuild or push a new commit. It works fine in that Pull Request/branch/Review App but for each new PR this process has to be repeated manually.
Is there any way to overcome this issue?
In case you have a similar issue, one approach that you can use(that worked for me)
app.json Heroku's convention file where you can list your buildpacks among many other settings.
For one of our repositories we set "Custom CI configuration path" inside GitLab to a remote gitlab-ci.yml. We want to do this to prevent Developers to change the gitlab-ci.yml file (as protected files are available in EE Premium and up). But except this purpose, the Custom CI configuration path feature should work anyway for Merge Requests.
Being in repo
group1/repo1
we set
.gitlab-ci.yml#group1/repo1-ci
repo1-ci repository exists and ci works correctly when we push to configured branches etc.
For Merge Request functionality GitLab tells us:
Detached merge request pipeline #123 failed for ...
Project group1/repo1-ci not found or access denied!
We added the developers to repo1-ci repo as developers, to be able to read the files. It does not help. Anyway the expectation is, that it is not run with user permissions, so it should simply find the gitlab-ci.yml file.
Any ideas on this?
So our expectations were right an it seems that we have to add one important thing into our considerations:
If a user interacts in the GitLab UI with the Merge Request features and you are using "Custom CI configuration path" for your gitlab-ci.yml file, please ensure
this user needs at least read permissions to that remote file, even if you moved it to another repo on purpose (e.g. use enhanced file protection in PREMIUM/ULTIMATE or push/merge protect the branches for the Developer role)
the user got this permission change applied in a running session
The last part failed for our users, as it worked one day later. Seems that they just continued working from their open merge request page and GitLab checks the accessibility out of this session (using a cookie, token or something which was not updated with the the access to the remote repo/file)
It works!
I am investigating adding an app.json file to my heroku pipeline to enable review apps.
Heroku offers the ability to generate one from your existing app setup, but I do not see any way to prevent it from automatically committing it to our repository's master branch.
I need to be able to see it before it gets committed to the master branch because we require at least two staff members to review all changes to the master branch (which triggers an automatic staging build) for SOC-2 security compliance.
Is there a way that I can see what it would generate without committing it to the repository?
I tried forking the repo and connecting the fork to it's own pipeline, but because it did not have any of our heroku add-ons or environment, it would not work for our production pipeline.
I am hesitant to just build the app.json file manually - it seems more prone to error. I would much prefer to get the automatically generated file and selectively remove items.
As a punchline to this story, I ended up investing enough time into the forked repository on it's own pipeline to demonstrate a POC
When you generate your app.json file, it should take you to a secondary screen that has the full app.json in plaintext at the bottom.
Why not open a PR with its contents in your project root. Once it's detected on the repository Heroku shouldn't ask you to regenerate it again.
I have a main app on heroku and another app A on git in location github:a.
I want to create, when it is necessary, copies of A as A1,A2,A3...AN as separate apps on heroku from my main app automatically with different parameters.
How can i do that?
Edit: This process should be done by my main app automatically.
Updating this answer due to Heroku command DEPRECATION:
heroku fork has been deprecated as a core command as of 12/01/2017.
You will need to install the heroku-fork plugin to continue using this command.
heroku plugins:install heroku-fork
Here is a link to the Github plugin repo.
Use heroku fork to copy an existing application, including add-ons, config vars, and Heroku Postgres data.
See this KB page: Forking Applications.
Heroku toolbelt now provides a fork method to clone an existing application, see my answer here :
how to clone a project on heroku
There is a new feature on Heroku called Review Apps. One can create copies of the app manually or set up automatic copies from new PRs on Github.
Read more at: https://devcenter.heroku.com/articles/github-integration-review-apps
Simply create new applications and push your code to them. If you need to copy data, checkout the pgbackups transfers.
For management purposes, check out this dev center article.
To do this programatically, you'll need to look at the Heroku gem, and then figure out a way of getting something to git push to the appropriate remote. I would be surprised if this was possible to be honest.
I made a Sinatra app, that will be hosted on Heroku, and the source will be up on GitHub. The problem is that i have a file with API keys, that is currently in .gitignore. Is there a way, that I can push my repo to heroku with the key file and exclude the file when pushing to GitHub?
Thanks in advance!
It is possible to maintain a separate branch just for deployment, but it takes much discipline to maintain it properly:
Add a commit to a production branch that adds the config file (git add -f to bybass your excludes).
To update your production branch, merge other branches (e.g. master) into it.
However, you must then never merge your production branch into anything else, or start branches based on any “production commit” (one whose ancestry includes your “add the keys” commit).
An easier path is to adopt Heroku’s custom of using environment variables to communicate your secret values to your instances. See the docs on Configuration and Config Vars:
heroku config:add KEY1=foobar KEY2=frobozz
Then access the values via ENV['KEY1'] and ENV['KEY2'] in your initialization code or wherever you need them. To support your non-Heroku deployments, you could either define the same environment variables or fall back to reading your existing config files if the environment variables do not exist.
The Figaro gem provides a good way to manage this issue. It basically simulates Heroku's environment variable approach locally, and makes it easy to keep your keys in sync between your development environment and Heroku.