Support running publishing bot for containerd

[akhilerm]

Currently the publishing-bot is centred towards running only on the kubernetes/kubernetes repo. We want to run publishing bot on the containerd/containerd repo to publish the api/ directory from containerd to a new containerd/api repository.

Following are the list of changes that must be made to so that this can be achieved without breaking the existing publishing bot workflow for k8s:

• add support for branch names containing "/" as containerd uses release/1.6 enable support for "/" in branch name #319
• workflow to test the changes in publishing bot add scripts to run/test publishing-bot locally #334 add new job to test publishing bot test-infra#29118
• support configurable main branch name add support for configuring default git branch #324
• support for multiple subdirectories in rules add support for multiple directories in rules #337
• updating debian base image and backport to support git-filter-repo add git-filter-repo via debian backports #336 update docker base image to bullseye #351
• change filter-branch to filter-repo use git-filter-repo instead of filter branch #369
• modify handling go mod related changes so that containerd specific changes can be done to go mod
• modify tagging logic so that tagging can be done as per containerd needs also
• add checks to ensure only newly created containerd tags are pushed and old tags/refs etc are not pushed to the containerd/api repo.

[BenTheElder]

Personally: I would really suggest considering just making containerd/api a go package / module instead.

The staging hack is not something Kubernetes can reconsider easily, but it can cause a lot of problems with IDEs etc (e.g. gopls won't support multiple modules without go.work) and it allows you to develop libraries without thinking as much about breaking changes versus if you consumed it as a library yourself ...

[akhilerm]

@BenTheElder Sorry for the delay in response.

For the containerd repo, it wont cause an issue with IDEs. The workflow that is in containerd/containerd for contributing and also the code organization in containerd repo will not change. We will not have a staging like directory in containerd. Just the /api directory and some dependent directories will be made available as containerd/api repo. The containerd/containerd will be consuming the apis from the directory itself. Only projects which need to use just the containerd api will be importing and using the containerd/api module.

I would really suggest considering just making containerd/api a go package / module instead.

This was earlier tried in containerd . Ref: containerd/containerd#5716. But didnt work out and had to revert the module changes, here. Ref: containerd/containerd#6439

[BenTheElder]

just the /api directory and some dependent directories will be made available as containerd/api repo.

I still don't recommend this because it means you're not experiencing how other users will experience using the package, which makes it too easy to ignore breaking changes etc.

This was earlier tried in containerd . Ref: containerd/containerd#5716. But didnt work out and had to revert the module changes, here. Ref: containerd/containerd#6439

I mean actually moving it out to another repo.

[akhilerm]

I mean actually moving it out to another repo.

Didnt get this part. Do you mean to completely move the api to another repository and then import containerd/api in containerd/containerd

[BenTheElder]

Yes.

[akhilerm]

@BenTheElder That will cause issue with tagging and using the containerd/api in containerd/containerd as it will involve back and forth tagging between the repositories to use a latest release version in containerd/containerd.

Hence following the publishing-bot approach, as it will handle tagging also and containerd community will not have to change their workflow.

Only consumers of containerd/api will have to import the new module instead of containerd/containerd as a whole.

[akhilerm]

@BenTheElder Do you have more thoughts on this?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[akhilerm]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[akhilerm]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[akhilerm]

/close as containerd has moved to using containerd/containerd/api module for releasing APIs

[akhilerm]

/reopen

[k8s-ci-robot]

@akhilerm: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[akhilerm]

/close

[k8s-ci-robot]

@akhilerm: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.