Skip to content

Fork Upbound build submodule #1583

@negz

Description

@negz

What problem are you facing?

Edit: Upbound decided to fork the Upbound build submodule. So internal Upbound projects are moving away from it (mostly to a fork, for now). This means there's nothing blocking us from moving (or forking) the submodule to the Crossplane org, to make it clear that it's only used by Crossplane now.

In addition to moving/forking it, I'd like to do a pass over it and remove anything that we know we don't use.


Currently Crossplane relies on a CI/CD system that could be opaque to community members who do not work for Upbound.

  • The majority of repos under the crossplane org use a git submodule of Make libraries that lives under the upbound org. This submodule is also use by several private repositories inside Upbound. This makes it difficult for community members to update, because their updates must account for potential impact on projects they could not possibly be aware of.
  • The build submodule is invoked by a Jenkins instance hosted at https://jenkinsci.upbound.io/. While this instance has some level of GitHub integration (i.e. GitHub org members may login and run and restart builds) it is hosted and administered by Upbound employees.

How could Crossplane help solve your problem?

At a minimum we should ensure Crossplane's CI/CD system is associated with "Crossplane" rather than "Upbound". This would involve forking the build submodule to github.com/crossplane/build, and hosting Jenkins at https://jenkins.crossplane.io.

We may consider taking this a step further and replacing Jenkins with GitHub Actions. This "GitHub native" CI/CD system may be less opaque to community members, and integrate more tightly with GitHub's native permissions model.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    Done

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions