Dear CF Devs,

The ARD working group will soon bump the base of the cloudfoundry/cf-deployment-concourse-tasks docker image to Go 1.20. [1]

We anticipate that most projects will be able to use the new docker image, and Go 1.20, for their existing use cases without any changes. However, we have noted at least one issue worth calling out: changes to the Go command in 1.20 have made it such that some binaries built on Linux are not compatible with other versions of Linux (ex: a Go binary compiled on an Ubuntu Jammy VM fails when pushed to cf-d with a cflinuxfs3 – Ubuntu Bionic – stack) unless compiled with the CGO_ENABLED=0 build flag. [2] [3]

If your project uses the latest tag of the cloudfoundry/cf-deployment-concourse-tasks image and you’re concerned about using Go 1.20, then you may want to consider locking to an older tag (i.e. v14.0.0) of the image for now. [4]

Best regards,

Carson Long

[1] https://github.com/cloudfoundry/cf-deployment-concourse-tasks/pull/147

[2] https://tip.golang.org/doc/go1.20#go-command

[3] https://github.com/cloudfoundry/cf-acceptance-tests/pull/750
[4] https://hub.docker.com/r/cloudfoundry/cf-deployment-concourse-tasks/tags

Dear CF Developers,

we'd like to share with you the rollout plan of cflinuxfs4 in cf-deployment [1].

The current cflinuxfs3 stack is based on Ubuntu Bionic and will reach end of life in April 2023 [2]. We will replace it with the Jammy-based cflinuxfs4 stack when all buildpacks are available. We are still waiting for the php- and staticfile-buildpacks. The status is summarized in [3].

Step 1 (when all buildpacks are available): We will publish a cf-deployment release with cflinuxfs4 as the default stack. The cflinuxfs3 stack will still be available and we will provide an ops file to revert to fs3 as the default.

Step 2 (latest in April): We will remove the cflinuxfs3 stack and buildpacks. An ops file to add the (unmaintained) fs3 components back will be provided.

Both releases will be cut as incompatible major releases.

Best Regards,

  Jochen.

[1] https://github.com/cloudfoundry/cf-deployment

[2] https://wiki.ubuntu.com/Releases

[3] https://github.com/cloudfoundry/cf-deployment/issues/989

Dear CF Devs,

The ARD working group will soon release a cloudfoundry/cf-deployment-concourse-tasks image that no longer includes an installed ginkgo CLI. [1]

We have successfully migrated most of our projects to v2 of the Ginkgo module [2], which has been out for long enough that we hope most other projects have been done the same. Therefore, we started using v2 of the ginkgo CLI as well. However, we couldn't just install the latest version of the ginkgo CLI in our docker image, as, ever since Ginkgo v2.3.0, the CLI and the local library versions are required to be in sync. This has led us to manage our ginkgo CLI version as a typical Golang tool dependency and install/use it on-demand in our projects. [3]

If your project uses the latest tag of the cloudfoundry/cf-deployment-concourse-tasks image and hasn't yet migrated to Ginkgo v2, then you may want to consider locking to an older tag of the image until you complete your Ginkgo v2 upgrade or adjust your workflows accordingly.

Best regards,

Carson Long

[1] https://github.com/cloudfoundry/cf-deployment-concourse-tasks/pull/127

[2] https://onsi.github.io/ginkgo/MIGRATING_TO_V2

[3] https://onsi.github.io/ginkgo/#recommended-continuous-integration-configuration

Dear CF Developers,

we will soon release a new major version of cf-deployment [1] which switches the default stemcell from Bionic [2] to Jammy [3]. From then on, we will run the cf-deployment release and evaluation process only with Jammy. If you have a custom CF deployment, you should check if an upgrade to Jammy is possible.

For Bionic, we will set up a basic validation which deploys a default CF installation and runs the CF Acceptance and Smoke tests. We will also provide an ops file to switch back the default stemcell to Bionic.

If you have questions, you can contact us in the cf-deployment Slack channel [4].

Best Regards,

  Application Runtime Deployments Working Group.

[1] https://github.com/cloudfoundry/cf-deployment

[2] https://bosh.cloudfoundry.org/stemcells/#ubuntu-bionic

[3] https://bosh.cloudfoundry.org/stemcells/#ubuntu-jammy

[4] https://cloudfoundry.slack.com/archives/C2U7KA7M4

At my place of work, we have concourse jobs which sends us messages on our MS Teams channel whenever a new release appears. Maybe this will be useful for someone else too.

Here’s some sanitised snippets from our release-notification-pipeline.

***

resources:

- name: java-buildpack-release

  type: github-release

  source:

    user: cloudfoundry

    repository: java-buildpack

    release: true

    access_token: ((github_token))

- name: notify-new-java-buildpack-releases

  plan:

  - do:

    - in_parallel:

      - get: release-notifications-pipeline

      - get: release-repo

        resource: java-buildpack-release

        params:

          globs: [notthisthing] # because we only want to watch for tag changes & data, not the release tgz itself (proxy won't allow download of it)

        trigger: true

    - task: check-versions

      config:

        platform: linux

        inputs:

        - name: release-notifications-pipeline

        - name: release-repo

        image_resource:

          type: docker-image

          source:

            repository: ((any_docker_image_which_has_curl_and_jq))

            tag: latest

        run:

          path: cf-deployment-notifications/check_versions.sh

      params:

        RELEASE_NAME: java-buildpack

        TEAMS_WEBHOOK_URL: ((ms_teams_webhook_url))

    timeout: 15m

***

.. and the source for the check_versions.sh script.

***

#!/bin/bash

set -e

if [[ -f "release-repo/body" ]]; then

  split --line-bytes=7500 release-repo/body release-repo/release-body-

  for file in $(find release-repo -name "release-body-*" | sort )

  do

    request_body=$(jq -n --arg body "$(cat "${file}")" --arg title "New $RELEASE_NAME $(cat release-repo/version) release" '{title: $title, text: $body}')

    curl -if -X POST --data "${request_body}" -k "${TEAMS_WEBHOOK_URL}"

    rm "${file}"

  done

else

  request_body=$(jq -n --arg body "The author was too lazy to add a release note" --arg title "New $RELEASE_NAME $(cat release-repo/version) release" '{title: $title, text: $body}')

  curl -if -X POST --data "${request_body}" -k "${TEAMS_WEBHOOK_URL}"

fi

***

Jim

Hi Carlos,