Skip to content

Move CI to CFF account #367

Open
Open

Description

@beyhan

To agent CIs should be hosted on CFF accounts, so that all approvers have access to it. Currently, it is host on Broadcom infrastructure and only Broadcom approvers can create new releases.

The agent supports also Windows and there are Windows integration tests executed during the validation. The move will require to explore options to execute the Windows integration tests on GCP where all the BOSH validations are hosted.

There is a Slack discussion here which has some more details.

Activity

  1. selzoc commented on Sep 22, 2025

    @selzoc
    Member

    If we are ok with the cost, the simplest thing to do would be to deploy a single windows 2019 worker in the FIWG concourse and move the pipeline over as-is. Anything else would require refactoring of the pipeline most likely.

  2. beyhan commented on Sep 23, 2025

    @beyhan
    MemberAuthor

    @selzoc which GCP instance type we will need for this? We could also have an approach like for the sole tenancy resource support I refactored in cloudfoundry/bosh-google-cpi-release#367. The sole tenancy instance is very expensive and it is started only for the integration tests execution and destroyed afterwards.

  3. selzoc commented on Sep 23, 2025

    @selzoc
    Member

    Our internal windows workers are configured like

    cpu: 8
    ram: 32768
    disk: 524288

    which is roughly equivalent to e2-standard-8 I think?

  4. beyhan commented on Sep 24, 2025

    @beyhan
    MemberAuthor

    Yes, I think that should be the recommended instance type.

    Here's a quick comparison for the total estimated monthly cost of an n2-standard-8 + Windows + 512 GiB Disk in us-central1:

    Plan Estimated Monthly Cost Best For
    On-Demand ~$541 USD Short-term projects, testing, unpredictable usage.
    1-Year Commitment ~$453 USD Stable workloads planned for at least a year.
    3-Year Commitment ~$388 USD Long-term, critical applications with a predictable need.
  5. selzoc commented on Sep 24, 2025

    @selzoc
    Member

    Also something I just realized is that the integration tests rely on a persistent bosh director that we have deployed, so we'd need either one of those in the CFF account or add a "deploy director" step into the pipeline.

  6. beyhan commented on Sep 25, 2025

    @beyhan
    MemberAuthor

    Actually, the Application Platform WG has also Windows validation tests. We could check with them how they use Windows Workers. Additionally, there is the initiative to have a central Concourse Instance provided by the Concourse WG and with this they could provide a Windows worker used by all CF components to execute Windows validations there. That is why when moving the pipelines we should also consider to move them directly to the central Concourse if it is available.

  7. aramprice commented on Sep 26, 2025

    @aramprice
    Member

    Some YAML snippets which might be helpful for getting windows workers setup with the FIWG concourse

    • Concourse pipeline.yml snippet:

    A bunch of details are left out of of this snippet because they area iaas specific

    jobs:
    # ... snip ...
    -   
      - name: deploy-workers
    
    # ... snip ...
    
          - put: external-windows-2019-worker-deployment
            inputs: detect
            params:
              cleanup: true
              manifest: "concourse-bosh-deployment/cluster/external-windows-worker.yml"
              ops_files:
                - "concourse-use-latest-release.yml"
                - "windows-worker-config.yml"
              releases:
                - concourse-bosh-release/release.tgz
                - windows-tools-release/release.tgz
                - windows-utilities-release/release.tgz
    
    # ... snip ...
    resources:
      - name: windows-tools-release
        type: bosh-io-release
        source:
          repository: cloudfoundry-incubator/windows-tools-release
      - name: windows-utilities-release
        type: bosh-io-release
        source:
          repository: cloudfoundry-incubator/windows-utilities-release
    
    • Ops File: windows-worker-config.yml
    - type: replace
      path: /releases/-
      value:
        name: windows-tools
        version: latest
    
    - type: replace
      path: /releases/-
      value:
        name: windows-tools-release
        version: latest
    
    - type: replace
      path: /releases/name=windows-utilities
      value:
        name: windows-utilities
        version: latest
    
    - type: replace
      path: /instance_groups/name=windows-worker/jobs/-
      value:
        name: golang-1-windows
        release: windows-tools
    
    - type: replace
      path: /instance_groups/name=windows-worker/jobs/-
      value:
        name: cmake
        release: windows-tools
    
    - type: replace
      path: /instance_groups/name=windows-worker/jobs/-
      value:
        name: make
        release: windows-tools
    
    - type: replace
      path: /instance_groups/name=windows-worker/jobs/-
      value:
        name: git
        release: windows-tools
    
    - type: replace
      path: /instance_groups/name=windows-worker/jobs/-
      value:
        name: ovftool
        release: windows-tools-release
    
    # Needed for Bosh-PSModules "Describing Protect-CFCell - disables the RDP service and firewall rule"
    - type: replace
      path: /instance_groups/name=windows-worker/jobs/-
      value:
        name: enable_rdp
        release: windows-utilities
    • Ops File: concourse-use-latest-release.yml
    - type: replace
      path: /releases/name=concourse
      value:
        name: concourse
        version: latest
  8. moved this from Inbox to Pending Review | Discussion in Foundational Infrastructure Working Groupon Oct 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions