-
Notifications
You must be signed in to change notification settings - Fork 54
Description
As can be seen here and here, there are lots of instances of the CI job deploy-gh-pages
executed on the non-default branch. This means that the online API documentation does not always reflect the current state of JavaSMT, but can contain unreleased APIs or show an old state, depending on which branch happens to have the newest commit in the repo. This is supposed to prevent this and I am sure it was working in the past, but it seems broken.
Given that only
is a deprecated GitLab feature, it does not seem worth trying to debug and fix this, but instead it seems wise to switch the CI config to exclusively use rules
instead of only
and except
. Note that rules
behaves quite differently and one has to think through in detail what happens in which situation in order to be able to write a replacement of the old config that behaves the same. I did this and pushed an updated CI config to our central template repository, and this seems to fix the problem for example in Java Common Lib. However, it seems that unfortunately JavaSMT uses a locally modified version of build/gitlab-ci.yml
with substantial changes, meaning that I applying this to JavaSMT will be more effort.
Side note: As stated in the comment at the top of build/gitlab-ci.yml
, I recommend to not change this file locally, and instead keep it in sync with our central template repository. As can be seen now, this would reduce the effort of maintaining the CI config. Technically, there should never be a reason that forces one to have local edits in this file: Improvements that are valid in general should be committed to our central template repository, and if there is anything that is specific to JavaSMT (such as the ARM jobs), it can be defined in .gitlab-ci.yml
. There one can also override and disable CI jobs from build/gitlab-ci.yml
if necessary.