Jenkins job structure

Trigger jobs

These are “entry points” called either externally (e.g. by GitHub) or in a cron-like fashion.

Flow - Github webhook

Called by GitHub when a push happens on neos/flow-development-collection

The job passes the following build parameters to downstream jobs:

  • payload - the full payload as given by GitHub
  • ref - the $.ref extracted from the payload, e.g. refs/heads/8.0
  • repository - the $.repository.full_name extracted from the payload, e.g. neos/flow-development-collection

For branch pushes, it triggers the following jobs:

  • Flow - update references

For tag pushes, it triggers the following jobs:

  • Update read-only splits

Neos - Github webhook

Called by GitHub when a push happens on neos/neos-development-collection

The job passes the following build parameters to downstream jobs:

  • payload - the full payload as given by GitHub
  • ref - the $.ref extracted from the payload, e.g. refs/heads/8.0
  • repository - the $.repository.full_name extracted from the payload, e.g. neos/neos-development-collection

For branch pushes, it triggers the following jobs:

  • Neos - update references

For tag pushes, it triggers the following jobs:

  • Update read-only splits

Flow - daily trigger

Run daily by Jenkins

The job passes the following build parameters to downstream jobs:

  • payload - a minimal payload as would be given by GitHub, only containing the ref and repository.url. The ref is built by parameter factories that need to be adjusted when new branches are added.

It triggers the following jobs:

  • Update read-only splits

Neos - daily trigger

Run daily by Jenkins

The job passes the following build parameters to downstream jobs:

  • payload - a minimal payload as would be given by GitHub, only containing the ref and repository.url. The ref is built by parameter factories that need to be adjusted when new branches are added.

It triggers the following jobs:

  • Update read-only splits

Other jobs

There are Event Sourced Content Repository - daily trigger and Event Sourced Content Repository - Github webhook, too, they take care of the ESCR project and are modeled after the other jobs…


Jobs run automatically

These are (usually) run automatically through one of the trigger jobs described above.

Update read-only splits

Uses https://github.com/neos/slicer to split the ref and repository given in the payload.

The job uses the following build parameters:

  • payload - the full payload as given by GitHub

Flow - update references // Neos - update references

These check out the corresponding development distriution, the PHP version used is switched between 7.4 and 8.0 depending on the ref and then Build/update-references.sh is run.

The job uses the following build parameters:

  • payload - the full payload as given by GitHub
  • ref - the $.ref extracted from the payload, e.g. refs/heads/8.0

neos-ui-build-minified

Runs bi-hourly and when triggered by neos-ui-release.

It checks out neos/neos-ui and runs Build/Jenkins/update-neos-ui-compiled.sh

The job uses the following build parameters:

  • GITREFSPEC_TO_BUILD - git refspec to build; e.g. “refs/heads/master” or “refs/tags/tagname”
  • GIT_BRANCH_MANUAL - Use only in case of emergency to create a manual build!
  • GIT_TAG_MANUAL - Use only in case of emergency to create a manual build!

Jobs run manually

These are run manually through the Jenkins UI as needed.

flow-create-branch // neos-create-branch

These prepare a new branch based on another branch. Use those to create a new development branch upon feature freeze.

The job uses the following build parameters:

  • SOURCE_BRANCH - the branch to base the new branch on, e.g. 8.0
  • BRANCH - the new branch to create, e.g. 8.1

The script Build/create-branch.sh is run by this job.

The PHP version used is 8.0 for the Flow job, but switched between 8.0 and 8.1 for Neos depending on the SOURCE_BRANCH.

flow-release // neos-release

These tag a new release. Use those to create a new release from a branch.

The job uses the following build parameters:

  • VERSION - the new version which is going to be released, e.g. 8.0.2
  • PREVIOUS_VERSION - The version which will be the previous version of the new release, e.g. 8.0.1
  • RELEASE_NOTES - (optional) release notes for Github

The BRANCH (and FLOW_BRANCH) to use are extracted from VERSION. Then the script Build/release.sh is run by this job.

The PHP version used is switched between 7.4 (for Neos 5 / Flow 6) and 8.0 (for other versions) depending on the major extracted from VERSION.

neos-ui-release

Tag a new UI release. This job does the following steps:

  1. update version dependency for Neos.Ui.Compiled in composer.json. Commit this change; but not to master, but only to the tag.
  2. tag the new release & push.
  3. Trigger the downstream job neos-ui-build-minified with the newly created tag. This will then build the tagged version for Neos.Ui.Compiled; so that they both fit together.

The job uses the following build parameters:

  • VERSION - the new version which is going to be released, e.g. 8.0.2
  • BRANCH - the branch to release.