Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert "Add a new github workflow 'tag'" #53

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

negz
Copy link
Member

@negz negz commented Jan 29, 2025

Description of your changes

This reverts commit a7522a4.

We don't use the tag workflow for functions. Instead we create tags via the GitHub UI when creating a new release.
Fixes #

I have:

This reverts commit a7522a4.

We don't use the tag workflow for functions. Instead we create tags via
the GitHub UI when creating a new release.

Signed-off-by: Nic Cope <nicc@rk0n.org>
We're upbound.io. upbound.com is a different business.

Signed-off-by: Nic Cope <nicc@rk0n.org>
@sergenyalcin
Copy link
Collaborator

sergenyalcin commented Jan 29, 2025

@negz The purpose of adding this workflow here is to ensure consistency in the release process with provider repos and other crossplane extensions (like upjet etc.). In other words, it is aimed to follow the same release process steps in provider and extension repos.

As ecosystem team, we believe that having the same release steps in all repos where we take responsibility for the release process will be a better practice in order to commonize the steps and determine the process. This workflow has been added in order to define a common path rather than which method is easier. Also, when we consider the whole process as an automation, I think, it is easier/more appropriate to trigger a workflow than a UI. This will also be more deterministic in terms of clarifying the process steps. In addition, keeping a record of running workflows is another benefit in terms of retrospective checks. This is something we take advantage of from time to time.

@turkenf
Copy link
Collaborator

turkenf commented Jan 29, 2025

In addition to Sergen's comment, having a workflow within the repo for tagging allows us to see the release history in GitHub Actions workflow logs. This makes it easier to track which tag was created, when, and by whom. Keeping the tagging workflow within the repo ensures that release-related processes remain more auditable and transparent. See an example for provider-aws

@negz
Copy link
Member Author

negz commented Jan 30, 2025

Function builds are already quite different though, right? They don't use the build submodule. This was an intentional design to avoid functions being as "heavyweight" as providers release and maintenance wise.

Is the intention to move these functions toward the same build tools and process as providers?

While I empathize with your team wanting to standardize, I would be disappointed if the function ecosystem started to trend toward the high level of complexity in our provider build ecosystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants