Skip to content

Conversation

@UweSchwaeke
Copy link
Collaborator

@UweSchwaeke UweSchwaeke commented Jan 22, 2026

crt: introduce --local-run option

  • what:
    introduce an option flag signaling the crt tool to run locally. "locally" means the tool will not access remote repositories. commands and subcommands that explicitly require remote access will simply ignore the flag.

  • why:
    this enables the crt tool to operate without a connection to remote repositories or the internet. it allows users to perform preparatory tasks—such as starting a release adding, removing manifests or adding patches, using only local data. a network connection is now only strictly required when finalizing the release.

@UweSchwaeke UweSchwaeke requested a review from jecluis January 22, 2026 12:55
Copy link
Contributor

@jecluis jecluis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@UweSchwaeke I've left some comments on the various commits.

Additionally, we need a proper description on this Pull Request, including what you are attempting to do. I'm a bit lost on what you are actually trying to achieve (maybe I forgot some of our initial chat on this).

So it would be nice to have the context on the PR description so we know what we are aiming for.

if not ctx.local_run:
# ensure we have the specified branch in the ceph repo, so we can actually obtain
# the right shas
# ensure we have the specified branch in the ceph repo, so we can actually
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch must be squashed/fixed up with the original commit introducing this change. We want a clean history of logical changes, not a history of all your changes regardless of what they are.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rewrote commits to squash some work in progress

Comment on lines 52 to 67
def with_local_run(
f: Callable[Concatenate[bool, _P], _R],
) -> Callable[_P, _R]:
"""Pass the flag to don't access remotes from the context to the function."""

def inner(*args: _P.args, **kwargs: _P.kwargs) -> _R:
curr_ctx = click.get_current_context()
ctx = curr_ctx.find_object(Ctx)
if not ctx:
perror(f"missing context for '{f.__name__}'")
sys.exit(errno.ENOTRECOVERABLE)
return f(ctx.local_run, *args, **kwargs)

return update_wrapper(inner, f)


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we adding this decorator? What benefit does that bring us?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this decorator is the same as with_patches_repo_path and with_gh_token. Some commands don't get the full Ctx. and therefore they get decorated with the with_,,, nethods to pass the option to it. At least this is myh understanding of those decorators

src_repo: str,
dst_repo: str,
token: str,
ceph_repo_path: Path, src_repo: str, dst_repo: str, token: str, local_run: bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please refrain from reformatting code that you do not need to reformat. This change should just be adding a new line to the end of the argument list, not rewriting the entirety of the argument list. You can let ruff do the right thing by adding a comma (,) at the end of local_run: bool.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, i removed unnecessary reformatting

Comment on lines 75 to 77
if local_run:
return

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to document why we're returning here. On a first pass it's not obvious to the reader.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i added a comment to the if statement

sys.exit(errno.EEXIST)
if local_run:
if git_get_local_head(ceph_repo_path, dst_branch):
perror(f"destination branch '{dst_branch}' already exists local'")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/local/locally/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, why are we bailing out if the branch already exists locally? Is there any reason why we can't update the local branch from a remote branch?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think because we shouldn't try to access remote branches if we run only local. i thought local_run is same as do not access remote repositories. Neither repositories located on github, nor repositories located on disk. Maybe i missed something.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i renamed the parameter to run_locally

ceph_repo_path: Path,
patches_repo_path: Path,
token: str,
local_run: bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be a keyword argument defaulting to False.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thx, made all to keyword arguments with defaults to False

Comment on lines +385 to +396
def git_remote(repo_path: Path, remote_name: str) -> git.Remote | None:
logger.info(f"get remote '{remote_name}'")

repo = git.Repo(repo_path)
try:
return repo.remote(remote_name)
except ValueError:
logger.debug(f"remote '{remote_name}' doesn't exists")

return None


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this change? It is not used in this patch at all.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks , i think i used it in another commit

git_get_remote_ref,
git_prepare_remote,
git_push,
git_remote,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The patch that introduces this function should be squashed/fixed up with this one. We should not have the same logical change scattered across different patches.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thx, i squashed and rewrote some commits

Comment on lines +440 to +457
if not (remote := git_remote(ceph_repo_path, dst_repo)):
pinfo(f"remote {dst_repo} doesn't exists local")
console.print(Padding(table, (1, 0, 1, 0)))
progress.done_task()
progress.stop()
return
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not seeing how remote here is used. Are we using git_remote() as the equivalent to a git_remote_exists() ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no later on it will be used

manifest.dst_repo,
release.release_repo,
gh_token,
False, # TODO pass local_run instead of hard coded
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this patch standalone if it's fixing something that we introduced earlier as a TODO? Are these changes different enough to be considered 2 logical changes? Or are they part of the same logical change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i introduced this TODO. sorry for that

@UweSchwaeke
Copy link
Collaborator Author

@UweSchwaeke I've left some comments on the various commits.

Additionally, we need a proper description on this Pull Request, including what you are attempting to do. I'm a bit lost on what you are actually trying to achieve (maybe I forgot some of our initial chat on this).

So it would be nice to have the context on the PR description so we know what we are aiming for.

I added a description.

@jecluis
Copy link
Contributor

jecluis commented Jan 29, 2026

@UweSchwaeke on the commits' subjects, I'll need you to add a colon (:) between the component being changed and the subject.

@UweSchwaeke
Copy link
Collaborator Author

@UweSchwaeke on the commits' subjects, I'll need you to add a colon (:) between the component being changed and the subject.

just a moment i will fix it

@jecluis
Copy link
Contributor

jecluis commented Jan 29, 2026

Also, please check the commit messages for typos. One example, the first commit shows:

don't check if release allready exists in remote

s/allready/already/

Additionally, ensure the commit messages are properly capitalized where it makes sense. While we don't want subject lines to be capitalized (unless required, e.g., to describe a CONSTANT_NAME), the commit message itself should come as easy-to-read text. I would also suggest adding a blank line between the commit's subject and the commit message body.

avoid accessing remotes if the flag is set and the subcommand doesn't require remote access.
affected subcommands:

* start:
  * skip adding remote URLs.
  * skip checking if the release already exists on the remote.
  * create a local release branch from base_ref (which must exist locally).
  * do not push the created branch or tag to the remote.

* list:
  * skip adding remote urls.
  * skip fetching from remotes.

other subcommands will ignore the flag.

Signed-off-by: Uwe Schwaeke <uwe.schwaeke@clyso.com>
don't access remotes if the flag is set and the subcommand doesn't require remote access.
affected subcommands:

* patchset add:
  * don't add remote urls and don't fetch patch branch (assume branch exists locally)

* validate:
  * don't add remote urls and don't fetch from remote

other subcommands will ignore the flag

Signed-off-by: Uwe Schwaeke <uwe.schwaeke@clyso.com>
don't access remotes if the flag is set and the subcommand doesn't require remote access.
affected subcommands:
* add:
  * don't add remote url and don't fetch

Signed-off-by: Uwe Schwaeke <uwe.schwaeke@clyso.com>
don't access remotes if the flag is set and the subcommand doesn't require remote access.
affected subcommands:

* add:
   * don't add remote url and don't fetch
   * create branch from an existing local branch

 * publish:
   * don't add remote url and don't fetch
   * create branch from an existing local branch

other subcommands will ignore the flag

Signed-off-by: Uwe Schwaeke <uwe.schwaeke@clyso.com>
@UweSchwaeke
Copy link
Collaborator Author

Also, please check the commit messages for typos. One example, the first commit shows:

don't check if release allready exists in remote

s/allready/already/

Additionally, ensure the commit messages are properly capitalized where it makes sense. While we don't want subject lines to be capitalized (unless required, e.g., to describe a CONSTANT_NAME), the commit message itself should come as easy-to-read text. I would also suggest adding a blank line between the commit's subject and the commit message body.

i added a better description ( mostly reviewed with gemini)

@UweSchwaeke UweSchwaeke marked this pull request as ready for review January 30, 2026 05:43
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.

2 participants