We have the following steps in our “pipeline” when we create a merge request. This “pipeline” is shared across 2 repositories, e.g. repo A & repo B.
Trigger unit tests
Netlify builds a deploy preview as the environment is configured to trigger on merge request events (regardless of success / failure of step 1)
Netlify adds a step in the pipeline (?)
Using Netlify functions we trigger a gitlab pipeline in repo B as soon as the site is deployed.
I would like to go to the following situation, preferably using .gitlab-ci.yml:
Trigger unit tests
(depending on output step 1) build a deploy preview
(depending on output step 2) kick off repo B pipeline
The .gitlab-ci.yml could be something like this:
stages:
- test
- deploy-preview
- e2e-tests
test:
stage: test
image: node:12
script:
- npm install --no-save
- npm test
e2e-tests:
stage: e2e-tests
script:
...code to kickoff e2e tests in repo B
Is something like this possible? Or would it be an alternative to resort to ‘manually’ deploying deploy previews using netlify-cli within .gitlab-ci.yml?
Hi @confusus, if I understand correctly, you are asking if there is some build integration with .gitlab-ci.yml? There is currently no .gitlab-ci.yml stage to do what you describe. You could probably use our build system to trigger your e2e tests either via a deploy notification or directly as part of your build command. Let me know if that makes sense.
Hi @Dennis! That is indeed what I was trying to ask. We couldn’t use the build system to trigger our e2e tests because it was a bit limited. I.e. the options given when configuring a outgoing webhook are:
Deploy request pending / accepted / rejected
Deploy started / succeeded / failed / locked / unlocked
Where we needed a notification only on a production branch deploy, hence the Netlify Function (which isn’t the most elegant solution…) to kick off our e2e tests.
How could we go about triggering e2e tests as part of our build command? Could the e2e tests still be triggered after the deploy?
Unfortunately it is still a bit finicky… Right now we’re running the e2e tests on a dedicated gitlab runner, where if we would use the plugin, the e2e tests would run on the netlify servers. These are a bit slower, causing our e2e tests to fail.
It describes several options for testing, but my preferred alternative to what you are doing is:
lock deploys so we don’t autopublish new commits
send deploy notifications to your CI server (maybe gitlab?) with every deploy
potentially filter those notifications at the CI server (or via zapier, who could for instance choose NOT to forward builds for deploy-previews since you don’t need to e2e test MR’s)
have it kick off tests which can take as long as you like
if successful, you can via API publish an existing deploy and re-lock; something like these two calls: