On Fri, May 31, 2024 at 03:11:34PM +0200, Peter Krempa wrote:
When the 'pages' job is configured to run
'on_success' it's skipped if
any other pipeline fails. This is bad in cases such as if an external
service runs out of CI minutes as the web stops being updated.
Since the 'artifacts' of the 'website_job' are generated only if that
phase succeeds this will update the web when the web part is buildable.
I guess I mis-understood 'on_success' as meaning failed jobs which
were dependencies, but you're right that the docs refer to *any*
failed job in an earlier stage. Pretty unhelpful :-(
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
Note that it's upnpleasant to test the pages deployment stuff separately
as various hacks are needed to do that successfully. Let's test this one
in production.
.gitlab-ci.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 7f80896e6e..d9d8b1e3cd 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -96,7 +96,7 @@ pages:
- website_job
rules:
- if: '$CI_PROJECT_NAMESPACE == $RUN_UPSTREAM_NAMESPACE &&
$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH ==
$CI_DEFAULT_BRANCH'
- when: on_success
+ when: always
- when: never
artifacts:
expose_as: 'pages'
Reviewed-by: Daniel P. Berrangé <berrange(a)redhat.com>
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|