Heroku Review Apps Url - heroku

We use a Heroku pipeline for deployment review apps for our Angular app. Recently we invested in EndTest codeless automation and we need to run the test suites on every review app that is created. The url's of these review apps are dynamic in Heroku, is there a way to capture this generated url and then execute a script that would trigger my test case suite in EndTest(EndTest has an API which can consume the url).
How do I get this done in Heroku environment. I just have PROC file configured.

You could use the postdeploy script:
The app.json file has a scripts section that lets you specify a postdeploy command. Use this to run any one-time setup tasks that make the app, and any databases, ready and useful for testing. Postdeploy is handy for one-off tasks, such as:
Setting up OAuth clients and DNS
Loading seed/test data into the review app’s test database
But if you will run this script with each change to a pull request, use release phase.
The app name should be in the env variable HEROKU_APP_NAME.

Related

Can I create Heroku Scheduler jobs via the CLI or other non-web UI method?

I'm working on a project which uses Heroku's 'Deploy to Heroku' button to allow people to quickly configure and deploy an app. The app includes a recurring task, and I would like to use Heroku's free 'Scheduler' add-on to run it every day. Ideally I would like the 'setup' task that runs on deploy to create a job in the scheduler, so that the user deploying the app doesn't have to do it.
Is this possible?
As far as I am aware, this is not possible using existing solutions.
I just created a new add-on, https://schedulerctl.com
Schedulerctl enables you to create and manage your Heroku Scheduler jobs using a REST API or the Heroku CLI.
These interfaces allow you to programatically combine Heroku Scheduler with other services like your Heroku button.

Is Heroku Release Phase one-off dyno exposed to the public network?

I want to run GhostInspector (or similar) as part of CI/CD. The tests would execute as part of the release phase for staging, then if successful, production will be deployed. Does this work? Is the dyno publicly accessible with the usual staging url?
short answer: one-off dynos are not publicly accessible to the internet.
For your use-case the way on heroku would be pipelines:
deploy your app to a testing-stage app
run ghost-inspector there
promote to production/staging afterwards
(you can control all this via easy cli or api-requests)
alternative: find a tool that runs headless (inside the dynos) or can be called from the dynos (Browserstack can be used like this in a CI/CD/Pipeline)

gcloud automatic redeployment Golang app

I have a Golang app running on Google Cloud App Engine that I can update manually with "gcloud app deploy" but I cannot figure out how to schedule automatic redeployments. I'm assuming I have to use cron.yaml, but then I'm confused about what url to use. Basically it's just a web app with one main index.html page with changing content, and I would like to schedule automatic redeployments... how do I have to go about that?
If you want to automatically re-deploy your app when the code changes, you need what's called CI/CD (Continuous integration/deployment). What a CI does is, for each new commit to your repository, check out the new code and run a test script. If all the tests pass (or if you don't have any tests at all), the CI server can then deploy your code to App Engine, all automatically.
One free (for open-source projects) CI provider is Travis CI. To configure it, you need to make an account with Travis, and a file called .travis.yml in the root of your repository. To set up App Engine deploys, you can follow this guide to set up a service account and add the encrypted file to your repo. It will run a gcloud app deploy from a container on their servers, whenever you push code to a certain branch (master by default) in your repo.
Another option, which avoids setting up CI at all, is to simply change your app to generate the dynamic parts of the page when it gets requested. Reading the documentation for html/template would point you in the right direction.

Postdeploy only at Pull Requests

I'm using Heroku Pipelines and what to run some scripts only when Heroku builds Review app. Now I use that line in my app.json:
"scripts": {
"postdeploy": "php artisan database:fill-test-data"
}
But I don't want to fill database with test data when anybody clicks on Deploy to Heroku button, because postdeploy scripts run at any first deploy. I want to fill database with test data only at Pull Requests.
Heroku has only 1 command that executed only at Pull Requests, and it is pr-predestroy.
The command is prefixed with “pr-” because it is ONLY run as part of
the pull request (PR) app flow.
But as far as I know there is no pr-postdeploy command. What can you suggest me to use as script command that will be executed only in Review apps created by Pull Requests?
Heroku Documentation: Review Apps
You could add an env var to the parent app (that it inherits from) that tells you it is a non-production app (i.e. staging or whatever) and then in your post-deply script, you could check if it that var is true
Your review app should not inherit from production app anyway, so assuming you are inheriting from a staging app or some other non-prod app, this should work.
let me know! I've struggled with review apps a lot

Can Laravel-Forge work with a CI cloud service?

My team and I were setting everything up so that Forge was in charge of deployment exclusively, while a CI cloud service would run unit/integration tests on each push to develop or master (staging or production, respectively).
Given the fact that Forge will trigger a deployment on each push to master (or any other branch), where does the CI server takes place in this model? Can I get a quick explanation of the workflow (and if possible an example CI cloud that would work with it)
Next to the auto deploy trigger Forge provides you a deploy-hook-url that can be called to trigger the deployment script. Usually the ci cloud service provides a way to customize the test/deployment process with some sort of bash scripts (curl) or gives an option to call an url after a successful run.
For example I used to use codeship for ci and they have an option in the settings called deployment where i could insert a custom script which calls the trigger url like curl -X GET https://forge.laravel.com/servers/xxx/sites/xxx/deploy/http?token=xxx
deactivate the aug-deploy trigger
customize the ci settings and call the forge-hook after successful run

Resources