We host our web app source code on GitHub, and whenever something's pushed to the master branch, it's deployed to Heroku via CodeShip.
Currently, we have two environments on Heroku: staging and production (we develop locally).
I've created a test suite for the website in PHPUnit (while using BrowserStack SaaS as a frontend for Selenium), and would now like to integrate that into our deployment pipeline.
How would I do that?
Heroku's new Review Apps seem like a good choice, but have in mind that I need to actually deploy the website app first and copy over the environmental variables.
This is how I imagine it should work:
Push to master on GitHub
CodeShip is triggered
PHPUnit tests are executed
A new version of web app is deployed to Heroku if tests pass
TLDR; I'm trying to integrate my PHPUnit tests into our Github -> Heroku pipeline, and only deploy if the tests succeed. How do I integrate the PHPUnit tests ?
Related
I can give the URL in cy.visit to point to deployed application, but I am not clear on the setup, as I don't have CI/CD yet. The goal is to be able to run this test on a button click, not having to checkout workspace and build the application.
I can give the URL in cy.visit to point to deployed application, but I am not clear on the setup, as I don't have CI/CD yet. The goal is to be able to run this test on a button click, not having to checkout workspace and build the application.
Yes, you could test your application directly on a staging/preproduction environment on AWS without A CI/CD.
However, I would not recommend using Cypress against a production environment because for E2E testing to be efficient, you will probably create/delete/edit many things, which may not be suited for a prod env.
Finally, it depends on what you try to achieve with your tests. In general, you will use Cypress to ensure your product works as expected after adding a new feature, for example. You always want to test against the latest version of your code.
On the setup, the E2E tests can be packaged in the project and run manually until you have a CI to execute them automatically.
https://docs.cypress.io/guides/guides/command-line#cypress-run
I followed the documentation here https://devcenter.heroku.com/articles/pipelines and setup a pipeline with two stages:
The above link only talks about how to promote an app, without specifying how to deploy, this section specifically (we can read beyond this point and see there is no instruction on how to deploy):
Pipelines let you define how your deployed code flows from one
environment to the next. For example, you can deploy code to your
staging app (which builds it into a slug) and later promote that same
slug to production. This promotion flow ensures that production
contains the exact same code that you tested in staging, and it’s also
much faster than rebuilding the slug.
So I used the same command we use for deploying non-pipeline based apps (as instructed here):
docker push registry.heroku.com/ultimate-hello-world-cra-stage/web
This appears to be a wrong approach. You can see in snapshot above that STAGING app did get deployed, but when I try to promote the app using this command heroku pipelines:promote --app ultimate-hello-world-cra-stage, I get this error: Error: Pipeline promotions are not supported on apps pushed via Heroku.
What is the correct way to deploy to a pipeline and where can I find it in the docs?
I am trying to set up Cypress end-to-end tests for a Vue SPA application that has to connect to a Laravel backend; the tests are to run in a Jenkins pipeline. This is practically straight forward in a local development environment. Basically:
Use docker-compose to spin up Laravel and DB
Use docker to spin up the SPA and then exec cypress run inside the container
However, I can't seem to think of an optimal way to set up something like that in a Jenkins pipeline. The SPA and Laravel are in separate repositories and I do not want to pull the one into the other while running the CI process; the thought itself seems messy.
So, basically, what is an optimal way to set up a Jenkins pipeline that does end-to-end cypress tests for a Vue SPA that has to connect to a Laravel API/MySQL DB?
This is my very first SO question and I apologise in advance if there are any rules I breached while creating it.
Cypress does not care where your BE is being hosted, it is set by your baseUrl.
Set up a deployment process for your BE repo on your Jenkins CI, which hosts the site at a subdomain of your ci server like e2e.example.com. Once your BE is deployed, then you can setup another job to deploy and test your Vue SPA.
If it was me, I would create one job and have it deploy first the latest/specified version of your BE, then deploy the frontend and run cypress. I have done this on an older project, with capistrano and jenkins and cypress, however mine was not an SPA in two repos so I did not have to do both deployments in one job.
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.
Background: I have a project deployed to heroku. The heroku app is connected with github so I can press the "deploy" button from heroku's web api to manually deploy a branch on github to heroku.
What I'm trying to do is build a slack bot that will let me accomplish that via a slack command. Ideally, there'd be some function on heroku's platform api like .deploy('my_app', 'some_branch_on_github), but I can't seem to find it.
The platform api's build feature is close. That function lets you provide the public url of a tarball that heroku will then deploy. However, my github repo isn't public, so that doesn't work. A private repo shouldn't be a problem, though, since heroku's already connected to my github repo.
TLDR: How can I programmatically tell Heroku to deploy my app from a private github it's connected to?
I got a response from Heroku's support team asking pretty much the same question. Their answer was that what I'm trying to do is not possible, but will be at some point (although not in the next few months, anyway).
They suggested that I could just use the undocumented web api used by heroku's own web console (a POST to an endpoint on kolkrabbi.heroku.com). They did warn that, as a private api, that's likely to change without warning.
As of April 2020, Heroku has integrated GitHub natively without recourse to any janky undocumented Icelandic endpoints.
When configured, Heroku can automatically build and release (if the build is successful) pushes to the specified GitHub repo.
Enabling GitHub integration
You can configure GitHub integration in the Deploy tab of apps in
the Heroku Dashboard.
To configure GitHub integration, you have to authenticate with GitHub.
You only have to do this once per Heroku account.
GitHub repo admin access is required for you to configure automatic
GitHub deploys. This is because Heroku has to register a service hook on
the GitHub repo, and this action requires admin access. For GitHub
organizations, your GitHub account will also need to be a member of the
organization and not an outside collaborator.
If your repo is in a GitHub organization that has third-party
application restrictions
enabled,
an organization admin needs to approve Heroku for use with the
organization. More details are available on
GitHub.
After you link your Heroku app to a GitHub repo, you can selectively
deploy from branches or configure auto-deploys.
Manual deploys
With manual deploys, you can create an immediate deployment of any
branch from the GitHub repo that’s connected to your app. Use manual
deploys if you want to control when changes are deployed to Heroku.
You can also use manual deploys to temporarily deploy a branch other
than the one that’s configured for automatic deployment. For example,
you might have a development app synced to the development GitHub
branch, but you temporarily want to test a feature branch. Simply
trigger a manual deploy of the feature branch to test it on the Heroku
app. Note that release of the feature branch is overwritten on the next
successful GitHub push to the development branch.
Automatic deploys
When you enable automatic deploys for a GitHub branch, Heroku builds and
deploys all pushes to that branch. If, for example, you have a
development app on Heroku, you can configure pushes to your GitHub
development branch to be automatically built and deployed to that app.
If you’ve configured your GitHub repo to use automated Continuous
Integration (with Travis CI, for example), you can check the “Wait for
CI to pass before deploy” checkbox. When enabled, Heroku will only
auto-deploy after all the commit statuses of the relevant commit show
success.
This commit won’t auto-deploy because one of the checks shows a
pending status:
This commit will auto-deploy because all of the checks show a status of
success:
Review apps
With review apps enabled for a Heroku app, Heroku will create temporary
test apps for each pull request that’s opened on the GitHub repo that’s
connected to the parent app. Review apps are great if you’re using
GitHub Flow to propose,
discuss, and merge changes to your code base. Because pull request
branches are deployed to new apps on Heroku, it’s very simple for you
and your collaborators to test and debug code branches. You can also run
automated integration tests on the Heroku app representing a GitHub
branch.
See the Review apps
article
for details.
Heroku CI
Once you’ve connected your GitHub repo to your Pipeline, you can turn on
Heroku CI, our
visual, low-configuration test runner that integrates easily with Heroku
Pipelines (and so complements Review apps, existing Heroku apps, and our
GitHub integrations). Any Heroku Pipeline is already Heroku CI ready –
just turn it on in the Pipeline’s Settings tab.
Links to diffs
For apps that are linked to GitHub repos, releases in the Dashboard
Activity tab will include a “View Diff” link. Following the link
will take you to the GitHub comparison view, showing the changes made
since the last release.
Disconnecting from GitHub
Terminate an obsolete GitHub connection, if necessary.
Disconnecting individual apps
Individual apps can be disconnected in the GitHub pane of the
Deploy tab for the app.
Disconnecting account
You can disconnect your Heroku and GitHub accounts in the Applications
pane on your Dashboard account
page.