There is a new “no-op” type of job available to customers, which does nothing. This is useful in some cases to shape complex workflows and simplify dependency relationships when there are large fan-in/fan-out scenarios.

Use “type: no-op” when defining a job at it does nothing.

some-job:
  type: no-op

For example, if you had a workflow for building and deploying a binary to several distribution channels you might have a configuration like this:

workflows:
  main:
    jobs:
      - build-binary
      - generate-docs
      - run-tests
      - publish-to-app-store:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-play-store:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-website:
          requires:
            - build-binary
            - generate-docs
            - run-tests

With the addition of a no-op job called “build” you could shape your workflow as follows:

workflows:
  main:
    jobs:
      - build-binary
      - generate-docs
      - run-tests
      - build:
          requires:
            - build-binary
            - generate-docs
            - run-tests
      - publish-to-app-store:
          requires:
            - build
      - publish-to-play-store:
          requires:
            - build
      - publish-to-website:
          requires:
            - build

This reduces duplication of requires stanzas and makes it easier to create new jobs both before and after “build” without making mistakes in the dependency relationships.

Customers have been asking for more flexibility when building dependency requirements between jobs. To date “requires” was based on the success of the required job. That is no longer the case. “Requires” now supports job status; success, failed, and canceled. So you can now build out complex dependency maps and fan in/out scenarios.

• When running complex fan-in/fan-out workflows, you may want to continue work even when there are test failures.
• When certain jobs fail or are canceled, you may want to execute cleanup jobs, or decide not to do a deployment.

Example Config

jobs:
      - a
      - b
      - c:
          requires:
            - a canceled
            - b:
              - failed
              - success
      - d:
          requires:
            - a: #defaults to success
            - b:
              - failed
              - success

Flexible requires, along with flexible when statements and expression based job filters, opens up more opportunities to optimize your pipelines for fast feedback and greater control of costs.

For more information on the feature visit the documentation.

We have added conditional support to when statements so you can do things like this: when: pipeline.git.tag == "release". The conditional support allows you to run workflows based on pipeline parameters and values.

For those looking to optimize their pipelines for fast feedback or cost, you now have additional capabilities to meet those objectives. We have also made some improvements to error messaging for those customers that may have invalid config.yaml post release. The error will be similar to this: “Error calling workflow: ‘workflow-name’ Expected valid pipeline variable”.

Please see previous notifications about this breaking change here.

For more about these new capabilities visit the docs.

The page Organization Settings > Overview now includes a new “Organization slug” section, which lets users view and copy in one click the slug of their organization.

Please note that all the following slug formats are valid:

• github/org-name
• bitbucket/org-name
• circleci/FMckQH4sfM6PsIPQEG1RLd

Updates:

• We’ve removed the ‘Scheduled Pipelines’ tab from Project Settings and added the ability to create scheduled pipelines via the ‘Trigger Type’ dropdown on the Project Settings > Triggers page.
• For users in organizations that are integrated with GitHub OAuth App, we have added a note on the ‘Add Trigger’ and ‘Add Pipeline’ pages that states they can now use GitHub App pipelines, triggers, and custom webhooks.
• If a user does not have a GitHub App pipeline for their project, we display a message on the Project Settings > Triggers page to direct users to create a GitHub App pipeline first before they can create a GitHub App trigger.
• When users delete a trigger, we’ve implemented an automatic page refresh so the deleted trigger is immediately removed from the list.

The pipeline value pipeline.trigger_parameters.webhook.body is now present for all GitHub App and Bitbucket Data Center pipelines, no matter how they are triggered.

This value was previously undefined for pipelines triggered via API, UI, or via Bitbucket Data Center push. This prevented customers from using this pipeline value in their config file if they wanted their pipeline to be triggerable from these event sources as well as from a custom webhook.

For pipelines triggered via custom webhook, the value of pipeline.trigger_parameters.webhook.body is the stringified event payload. For all other methods of triggering, the value is now set to {}.

NOTE: This value is still not set for OAuth pipelines.

Updates:

• Added a ‘Remove all’ button to allow users to easily remove parameters for specific projects
• We display in-modal error states when users input duplicate parameter names, have a missing config file in their selected branch, etc.
• When users manually add a parameter, the new row will now appear at the top of the list instead of the bottom, making it easier to spot and fill in

CircleCI will be moving to twice-yearly major and minor version releases of Server. Releases will be targeted for Spring (April) and Fall (October). Patch releases for bugs and security updates will be made monthly as needed.

We will support two minor releases or 1 year from the date of the release. This is a change from the current 4 minor releases or 1 year from the date of the release. After the April release of server 4.8, supported versions of server will include server 4.8 and server 4.7.

A catch-up release will be made available in the coming months that will allow existing customers to upgrade from 4.3, 4.5, and 4.6 variations to the most recent server version 4.7. Allowing customers to get to a supported version before we release 4.8 in April.

Server release 4.8 is planned to include some new features. The first enables more flexibility in defining which jobs or workflows run using conditional expressions. The second is the introduction of an observability stack that will enable proactive monitoring of the state of the server installations.

We are making some changes to when statements for workflows December 3rd. We will be adding conditional support to when statements so customers can do things like when: pipelines.git.tag == release. This conditional support allows for customers to run workflows based on pipeline parameters and values.

NOTE: When in Steps are not impacted by this change.

If you currently have when: always in your workflows you will need to make a change to your config. Always has never been a special value for workflow when, it is a non-empty string and currently evaluates as true. This is equivalent to removing the when key from your workflows.

Shortly the “always” string will be interpreted as an expression and will fail. To avoid your config failing to be processed you must remove the when from your workflows, which is equivalent to the prior behaviour.

For organizations that integrate with GitHub App, GitHub OAuth App, Bitbucket Cloud, and Bitbucket Data Center, we now pre-populate pipeline parameters when triggering pipelines in the CircleCI web app.

For more details or to share feedback, visit our community forum.

GitHub App triggers, previously uneditable, can now be edited.

Specifically, users can edit the following fields:

• Trigger name
• Config branch (if present)
• Checkout branch (if present)

Updates:

• For projects with a single pipeline, the modal now defaults to that pipeline, so users no longer need to select it from the dropdown
• Automatically populate the branch in the dropdown when users are on the Project > Branch page
• Added the ability to search in the branch dropdown within the modal
• Rolled out a fix so the text no longer duplicates when users copy and paste into the parameter inputs

The page Project Settings > Overview now includes a new “Project Slug” section, which lets users view and copy in one click the slug of their project.

Please note that both the following project slug formats are valid but mutually exclusive by project:

• github/org-name/project-name
• circleci/FMckQH4sfM6PsIPQEG1RLd/4CNEcx&6Yk6wkpwo2ft9Uo

Before Upgrading

See the CircleCI server 4.7 release notes and upgrade guide for this release.

NOTE: Vault is being deprecated and will no longer be supported in server 5.0. Refer to our script for steps to migrate to Tink.

What’s New in Release 4.7.0

The v4.7 release introduces security improvements with the implementation of rootless containers.

NEW FEATURES

• Approval jobs can now be canceled through the CircleCI UI or via the API.

CHANGES

• Server components now run as rootless containers, enhancing security.
• The Nomad server ReplicaSet is now scaled to 5 pods by default, which improves execution stability at scale.
• Configuration for the RabbitMQ PersistantVolumeClaim (PVC) is now exposed through server Helm values. For more details, see the docs.

BUG FIXES

• Resolved an issue where frontend pods would not automatically detect and apply a new server license.
• Fixed a bug where a workflow could be prematurely marked as failed before all non-blocking jobs were run.
• Fixed a configuration issue that could cause connection refusals between Kong and Soketi following an upgrade to version 1 of Soketi.
• Addressed a typo in the Helm values for machine_provisioner.machine_agent_base_url. The correct template value should be machine_provisioner.agent_base_url.

SERVICE CHANGES

Deprecated components removed with this release:

• web-ui-404: Previously served the 404 error page. Its functionality has now been merged into the main web-ui component.
• Support for GitHub Enterprise versions <= 2.2: Code supporting these versions has been removed, as they are no longer supported by GitHub.

DATABASE MIGRATIONS

The following databases will run migrations when upgrading to this version:

• authenticationservice
• conductor_production

KNOWN ISSUES

• SSH reruns in air-gap will time out, leaving the job in an error state
• Vault may not refresh its client token after a month of uptime. Migrate to Tink to resolve this issue.
• Retry with SSH for jobs using the machine executor advertises a private IP address. For this reason, retry with SSH for jobs using the machine executor works as standard for public installations, but for private installs you would need to ensure that you can access the private IP advertised. For example, by using a VPN into your VPC.
• CircleCI 1.0 builds are not supported. If an attempt is made to run a 1.0 build, no feedback will be available in the application to indicate the cause of the issue. If a build is run on your installation and does not show up in the CircleCI application, use the CircleCI CLI to validate the project configuration and get details of the possible cause of the issue.

To learn more about Server 4.7 installation, migration, or operations please review our documentation.

IP Ranges now support parameters providing more dynamic control of when ip ranges is used in builds.

Example

version: 2.1

parameters:
  ip_ranges:
    type: boolean
    default: true

executors:
  base:
    docker:
      - image: cimg/base:stable

jobs:
  job_a:
    executor: base
    circleci_ip_ranges: << pipeline.parameters.ip_ranges >>
    steps:
      - run: echo "Running job a"

workflows:
  workflow-a:
    jobs:
      - job_a