Review apps are not deployed automatically.

Currently the test scenario of the merge request pipeline triggers creation of an automatic MR review app.

It would be sufficient for the mandatory test to create a build, without automatically creating a review app.

Creating a review app should remain a manual choice, eventually aided by with MR slash commands issued in comments received by a bot. At least GitHub has CI actions for that.

–

• Creating an MR only runs a build, without deploying it.
• It is possible to manually issue a review app for a selected MR.

added flow::ready label

mentioned in merge request !22 (merged)

mentioned in merge request !23 (merged)

added flow::doing label and removed flow::ready label

added flow::review label and removed flow::doing label

mentioned in merge request !24 (merged)

This is now sufficiently working.

• refactored schema script in package.json to accept input from CI environment instead of Sops.
• added PUBLIC_DIRECTUS_URL and DIRECTUS_STATIC_TOKEN as CI variables
• decoupled test and deploy steps
• set test-app to manual
  • this comes at the price that the button with the test app URL is not showed anymore in a MR
  • active environments remain visible from Environments · ecobytes / web · GitLab

While early experiments used four jobs with a build and test stage, they also wasted two minutes on a job that basically did nothing.

• https://lab.allmende.io/ecobytes/web/-/pipelines/677/builds

This job has been cut out now:

• https://lab.allmende.io/ecobytes/web/-/pipelines/681/builds

It is possible to deploy a test app while the MR is open and the branch exists/is not deleted yet by pressing the play button next to the test-app job, once the test job uscceeded.

• https://lab.allmende.io/ecobytes/web/-/pipelines/681/

Merging the MR will also destroy the test app.

---

There are two alternative paths to solving this story:

1. Using GitLab Pages together with its CI artifacts integration.

• Every GitLab Page deserves a real CI/CD | K33G's website
• git - Deploying GitLab pages for different branches - Stack Overflow

In our case we can demonstrate, that every (recent) job has browsable artifacts, which can be web pages.

• test (#1708) · Jobs · ecobytes / web · GitLab
• public/dist · Artifacts · pages (#1712) · Jobs · ecobytes / web · GitLab
• Artifacts · pages (#1712) · Jobs · ecobytes / web · GitLab
• Home

2. Using the experimental pages:pages.path_prefix feature behind the pages_multiple_versions_setting, which allows to deploy branches into subfolders (for now–there are issues about subdomain-based deployments of branches for multiple versions / review apps)

• CI/CD YAML syntax reference | GitLab
• Enable and disable GitLab features deployed behind feature flags | GitLab

In both cases we would need to support building against a site path.

For (1) we'd need to evaluate CI_JOB_ID for deterministically building the URL and for (2) we can continue to use CI_COMMIT_REF_SLUG.

marked the checklist item Creating an MR only runs a build, without deploying it. as completed

marked the checklist item It is possible to manually issue a review app for a selected MR. as completed

@upsiflu Would you like to try creating a review test app upon one of the next MRs?

assigned to @yala

assigned to @upsiflu and unassigned @yala

I've just clicked on the play button on !29 (merged) to get another example.

I would still be interested if this kind of workflow would also work from your side @upsiflu.

Could you check if you could create a similar review deployment of the website with a test app job, e.g. by clicking this play button that reveals after clicking on the pipeline icon on !27 (merged), as seen above?

stop-test-app will be automatically initiated upon merging the MR.

The pipelines work now as expected, closing.

Next iterations may like to increase build and deployment speed. #59 (closed)

closed

marked this issue as related to #59 (closed)

mentioned in issue #59 (closed)

marked this issue as related to #58 (closed)

mentioned in issue #58 (closed)