The gitpython package is a popular package that makes pygitops possible.

We should reference this package as the basis for our implementation and describe the differences between the two packages - especially when it comes to deciding when / how to use either one of them

Description

Documentation changes don't seem to be making it to the docs site. For example, the Development Guide.

Docs Site, and the corresponding changes that should be there

I propose adding the following to the readme:

• Overview of the project
  • Perhaps a list of cool features
• A short example
• Installation and import instructions

You can find a good example here.

As a maintainer of this repository, I would like pull requests to require a review from a project maintainer before being able to merge

Could branch protection rules be configured such that 1 approval from a project maintainer is required before being able to merge? (I am unable to configure this setting myself)

Thanks!

This keeps the operations file more clean and appropriately separates concerns.

It may be worth-while to move this into a _github_utils.py file (in which the function created in #52 could also reside).

Blocks #53 .

Read through the code to understand what is going on here.

On a cursory reading of the code, I'm not sure why the current structure is better than making the branch parameter optional and, if it is None, getting the default branch.

Description

👋 This repository is not currently configured for Renovate. This issue proposes the steps necessary to add Renovate to this project!

💡 Not familiar with Renovate, or are confused about what advantages it holds over GitHub's Dependabot? Learn more here!

Steps to Add

1. Review the guide for Adding Renovate to Existing Projects.
2. Add a comment to this issue as a signal to others that you intend to work on it. The OSPO will then assign the issue to you. If you ultimately decide not to pursue this, please remember to let us know via comment so that others may participate!
3. If the renovate[bot] account has already auto-filed a Configure Renovate PR against this repository, feel free to reference the proposed changes in your own Pull Request. If you are contributing to this project as a Hacktoberfest participant, you must file your own PR in order to get credit for your contribution!
4. You may find that the CI build for this project is failing for unrelated reasons. If you are not already a contributor to this project and don't feel comfortable attempting to fix the build, that's okay! There's plenty of other ways you can contribute to Wayfair's open source projects :) Feel free to consult the list of our other participating repositories here!
5. In order to catch potential JSON syntax errors or other mis-configurations, please add Renovate linting to this project's existing GitHub Workflow CI pipeline, or create a new one (eg. .github/workflows/lint.yml). See here for an example.
6. If this repository is currently configured to use GitHub's Dependabot, you must also deprecate support for Dependabot in order to avoid conflicts with Renovate. This is typically as simple as removing the .github/dependabot.yml file. See here for an example.

Checklist

• I have read the Adding Renovate to Existing Projects guide.
• I have assigned this issue to myself avoid duplicating efforts with other potential contributors.
• I have verified this repository does not already have Renovate configured (or proposed in an open PR by another contributor).
• If the renovate[bot] account has already auto-filed a Configure Renovate PR in this repository, I confirm that I will create a separate PR under my own GitHub account, using the initial PR as inspiration.
• I confirm that I have added Renovate linting to this project's existing CI pipeline, or have created a new linting workflow if one doesn't already exist.
• If this repository is currently configured to use GitHub's Dependabot, my PR will also deprecate support for Dependabot in order to avoid conflicts with Renovate.

Use pyproject.toml and static metadata.

Consolidate the examples in the index and usage guides.

As a contributor to this package, I would like to have the codecov bot provide codecov data for PRs

From a cursory reading of the code, it seems that this function should be private. Look into this a bit and, if my hunch is valid, make it private.

Update the docs so that they can be filtered based on version as was done in the Columbo docs.

In the get_updated_repo there is code to scrub the token from the github url when logging it. This should be generalized and moved into the _utils.py file.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency GitPython to v3.1.41 [SECURITY]
• Update dependency black to v24 [SECURITY]
• Update GitHub Actions (codecov/codecov-action, ncipollo/release-action, pypa/gh-action-pypi-publish, suzuki-shunsuke/github-action-renovate-config-validator)
• Update Python (bandit, isort, mkdocs-material, mkdocstrings, mypy, pytest, pytest-cov, pytest-mock)
• Update python Docker tag to v3.11
• Update GitHub Actions (major) (actions/checkout, actions/setup-python, actions/upload-artifact, codecov/codecov-action, suzuki-shunsuke/github-action-renovate-config-validator)
• Update Python (major) (flake8, mike, mkdocs-material, mypy, pytest, pytest-cov)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Once docs are written (see #12), we should serve the docs - probably via github pages. The docs will only be served via github pages once the repo is public.

To manage versions in this library, we should use bump2version.

Create an API reference for pygitops, documenting all publicly exposed functions, types, exceptions, etc

Our development guide should document how to publish new versions of the package

Relocate source code from wayfair internal pygitops repository

Context

The feature branch context manager has the following pre conditions:

• working directory cannot have untracked files
• active branch must be the repository's default branch

If the above preconditions are not met, a PyGitOpsError will be raised.

When we exit context, we will make sure to checkout the repo's default branch.

However, we are not doing anything in the way of "cleaning up" the working directory.

Proposal

Our feature_branch post conditions should be in line with the expected preconditions

Upon context exit, we should clean up the working directory.

The overall user story here is:
As a user of pygitops.feature_branch, I would like to be on my repo's default branch with a clean working directory both before and after being in context.

Write a usage guide for the package.

Link to it from:

• development-guide
• getting-started
• index

Since our function docstrings are used in the autogenerated api reference, we should ensure that they are:

• complete
• make sense
• correctly formatted

The get_updated_repo function has an interface that does not allow for callers to indicate the desired clone path of repositories.

The function currently takes in the clone_dir and repo_name args, and builds the clone location by concatenating the two arguments. In this format, users of this function cannot fully specify their desired location of the repository on disk.

As a user of get_updated_repo, I would like to be able to specify the desired clone path. I would also like control over the name of the directory.

Proposal

Can we make the following breaking change to the behavior and interface of get_updated_repo?

• Instead of building dest_repo_path here, can we use the provided clone_dir arg directly as the --directory argument to Repo.clone_from? This way, the clone_dir arg will directly be used in the git clone command as the --directory arg: https://git-scm.com/docs/git-clone#Documentation/git-clone.txt-ltdirectorygt. This will tell git exactly where to clone the repository, and what directory name to use. Users of get_updated_repo will have full control over clone path.
• Can we build the git lockfile path using the clone_dir arg, instead of the repo_name arg? Since we are locking a specific directory on disk, it actually makes more sense to lock based on the clone_dir argument, since that is where the repository will be cloned into.
• Can we remove the repo_name argument from the get_updated_repo? This will simplify the interface, and go along with the change in behavior

Make sure there is a test case which uses the feature_branch context manager twice (one use within the other use) to make sure the repo locking is working properly. Also, read through the code to make sure I understand and can document how repo locking works.

Currently, pygitops requires "dataclasses==0.6". But dataclasses is a backport for python3.6 and should not be installed if the python version is >= 3.7. Update the dataclass version to have an environment marker limiting the python versions for which the dataclasses library will be installed.

As noted in this comment, the FILELOCK_ACQUIRE_TIMEOUT_SECONDS is not particularly configurable. Investigate ways to make FILELOCK_ACQUIRE_TIMEOUT_SECONDS more easily configurable (this would be very helpful in the tests for this library).

If there is a good way to make this more configurable, implement it and create another ticket to update the tests in this library to set the timeout to a small value by default to limit the time it takes for tests to finish.

Use Case

Since this library will mostly be used by automated systems, it would be useful if it could cleanly handle the case of wiping and pushing new changes to an existing branch.

One way to do that in git is:

1. pull down the latest version of main
2. checkout the given feature branch
3. git reset --hard origin/main
4. allow the user to make code changes
5. commit the changes
6. force push the contents to remote

Potential interface:

with force_push_to_feature_branch(branch_name):
    # Make code changes

This could raise exceptions if:

1. There were no code changes
2. The branch name given didn't exist

On exit, the context manager would abandon any uncommitted changes, and checkout main, leaving the repo in a clean state.

checkout_pull_branch() to perform a pull, but this doesn't work when the local copy has untracked changes:

Traceback (most recent call last):
  File "/pyenv/versions/[redacted]/lib/python3.9/site-packages/pygitops/operations.py", line 193, in get_updated_repo
    _checkout_pull_branch(repo, branch)
  File "/pyenv/versions/[redacted]/lib/python3.9/site-packages/pygitops/_util.py", line 82, in checkout_pull_branch
    origin.pull(branch)
  File "/pyenv/versions/[redacted]/lib/python3.9/site-packages/git/remote.py", line 910, in pull
    res = self._get_fetch_info_from_stderr(proc, progress,
  File "/pyenv/versions/[redacted]/lib/python3.9/site-packages/git/remote.py", line 750, in _get_fetch_info_from_stderr
    proc.wait(stderr=stderr_text)
  File "/pyenv/versions/[redacted]/lib/python3.9/site-packages/git/cmd.py", line 502, in wait
    raise GitCommandError(remove_password_if_present(self.args), status, errstr)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(1)
  cmdline: git pull -v origin main
  stderr: 'error: Your local changes to the following files would be overwritten by merge:'

Suggested Fix

We could allow an optional force arg to be provided. If set and True, we would pass this option to the git checkout command to discard any changes to the index and working tree. An additional git clean command could also be run to remove untracked files.

We should add dependabot support via dependabot's v2 config

Currently, the action to upload this package to pypi will be released when a new tag is pushed or when a release is published. Update this to only deploy to pypi when a release is published.

All relevant project badges should be present in the README and docs landing page:

• CI status
• pypi version
• supported python versions
• codecov

• Add 3.10 to the set of python versions the code base is tested against in CI.
• Update the package classifiers.