Giter VIP home page Giter VIP logo

hyp3-cookiecutter's Introduction

HyP3 Cookiecutter

Use Cookiecutter to quickly generate a new HyP3 Plugin.

Usage

1. Create the plugin with Cookiecutter

To create a new plugin, you'll first need to run the cookicutter. From a terminal on your local development machine, navigate to where you'd like to create the local copy of the plugin's repository. Then run cookiecutter and follow the prompts:

python3 -m pip install cookiecutter
cookiecutter https://github.com/ASFHyP3/hyp3-cookiecutter.git

Now, you should have a hyp3-<process> directory which contains a minimal HyP3 plugin.

2. Create a repository on GitHub

Next, we'll need to create a new repository on GitHub for your plugin. Make sure to create your repository in the same user/organization account you set in the <GITHUB_USERNAME> field of the cookiecutter.

Your repository name should be the same as the directory name for the plugin you created on your local develop machine. (e.g., hyp3-<PROCESS_TYPE>). For the description section, you can copy in the short description you created in the cookiecutter step. You can find this in your newly-generated, README.md file, or in your command line history. Next, set the repository to "Public", and do not click the "Initialize repository with a README" box (or add a .gitignore or add a license).

3. Setup a development environment

We use a conda/mamba environments to manage our dependencies; you can get Mambaforge (recommended) here:

https://github.com/conda-forge/miniforge#mambaforge

And you can get Miniconda here:

https://docs.conda.io/en/latest/miniconda.html

Once conda is installed, from the repository root, you can create and activate a development environment with all the necessary dependencies

cd hyp3-<process>
conda env create -f environment.yml
conda activate hyp3-<process>

You should now have a development environment with all the required packages for a generic HyP3 plugin. Later, as dependencies change, you can edit the environment.yml file and then update your environment with

conda env update -f environment.yml

4. Push the repository to GitHub

We want to push the local copy we just created to our GitHub repository:

# From hyp3-<process>
git init .
git remote add origin https://github.com/<GITHUB_USERNAME>/hyp3-<PROCESS_TYPE>.git
git add .
git commit -m "Minimal HyP3 plugin created with the hyp3 plugin cookiecutter"
git branch -M main
git push -u origin main

We also want to create a zeroth production version from this initial commit so that the plugin's auto-versioning will work correctly.

git tag -a v0.0.0 -m "Marking zeroth release for auto-versioning and CI/CD Tooling"
git push --tags

Then add a development branch:

git checkout -b develop
git push -u origin develop

5. Configure the GitHub repository settings

Once the zeroth release is pushed to GitHub, we need to configure the GitHub repository settings. The settings detailed here are not required, but we STRONGLY recommend them as they make it much easier for others to collaborate on your project, and for you to control how the collaboration occurs.

Go to your repository in GitHub and on the right, click "Settings", then:

  1. In main page:
    • In the "Pull Requests" section
  2. In "Branches":
    • make sure the default branch is "develop"
    • Add a "Branch protection rule" for:
      • main:
        • set "Branch name pattern" to "main"
        • click "Require pull request review before merging"
        • click "Dismiss stale pull request approvals when new commits are pushed"
        • click "Require status checks to pass before merging"
        • click "Do not allow bypassing of the above settings"
        • click "Restrict who can push to matching branches"
        • Create
        • See Main branch rules section screenshot for configuration image
      • develop:
        • set "Branch name pattern" to "develop"
        • click "Require pull request review before merging"
        • click "Require status checks to pass before merging"
        • click "Do not allow bypassing of the above settings"
        • Create
        • See Develop branch rules section screenshot for configuration image

For both the main and develop you can restrict who can push to the branch. In the same page where you set the above options, you can also click "Restrict who can push to matching branches", then search and add the desired people/organizations who are allowed to push. If you set this, make sure you include the owner of your repository in this list - other your GitHub Actions won't work!

For more information on how to contribute to repositories set up in this manner, check out GitHub's GitHub flow article

6. Create a personal access key for GitHub Actions

Some of the GitHub actions (release.yml and tag-version.yml) need extra permissions to work properly. These actions will attempt to use the GITHUB_PAK secret to assume a user profile with the needed permissions, so we'll need to create the permissions/secret.

  1. In your user/organization settings:
    • Click on Developer Settings
    • Click on Personal access tokens
    • Click Tokens (classic)
    • Click Generate new token
    • Click Generate new token (classic)
    • In the note section give the token a name (e.g., GITHUB_PAK)
    • Check the boxes for:
    • Click Generate token
    • Copy your access token and save it for the next step
  2. In your HyP3 plugin repository:
    • Click on Settings
    • Click on Secrets and variables
    • Click on Actions
    • Click on New repository Secret
    • Name your secret GITHUB_PAK
    • Paste in the access token you save from the last step
    • Click Add secret

This access token will regularly expire unless you set them to last forever (which we don't recommend) so make sure to keep the token current and the secret up to date!

7. Restart the GitHub Actions

Now you're all setup! You should be able to navigate to your repository "Actions", restart the failed Workflows on develop, and watch it create minimal HyP3 plugin container for your process.

8. Make HyP3 plugin container public

Once the Actions have successfully run, a containerized version of your plugin will be available in the GitHub Container Registry (GHCR). You can find this plugin in the "Packages" section of your GitHub user/organization account. You can also pull it to your local machine for use using the command:

docker pull ghcr.io/<GH_ACCOUNT_NAME>/<GH_REPOSITORY_NAME>

GHCR containers are private by default. You'll need to manually change the visibility of your container to "Public" so that HyP3 can access it. See this GitHub Documentation for a step-by-step guide.

Screenshots

PR Rules

PR Rules screenshot

Main Branch Rules

Main Branch Rules screenshot

Develop Branch Rules

Develop Branch Rules screenshot

GITHUB_PAK Permissions

GITHUB_PAK Permissions screenshot

hyp3-cookiecutter's People

Contributors

asjohnston-asf avatar dependabot[bot] avatar forrestfwilliams avatar jhkennedy avatar jtherrmann avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

hyp3-cookiecutter's Issues

Do we want to provide a processor-based template (as well)?

Right now, the cookiecutter assumes we're making a plugin that will run one process (workflow) and create one type of product.

This is how hyp3-autorift is organized and how we historically made plugins, but we've moved to a more "processor" based plugin for most of our plugins:

  • hyp3-gamma produces RTC (was hyp3-rtc-gamma) and InSAR (was hyp3-insar-gamma) products
  • asf-tools produces water map and flood map products
  • DockerizedTopsApp creates GUNW SLC and Burst SLC products

Supporting multiple products is typically done via a python entry points and argparse trick. Similarly,

  • RAiDER only provides one HyP3 entry point but does provide others as it was an existing tool we added support to

We could:

  1. Always include the basic entry point + argparse setup for multiple plugins (overly complicated and likely confusing when not needed), or
  2. Provide both templates via: https://cookiecutter.readthedocs.io/en/stable/advanced/directories.html
  3. Ask how many products this plugin will make (now, or later) and conditionally add in the entry point + argparse setup
  4. Just document the entry point + argparse setup

Provide multiple tailored cookiecutters

Since cookiecutter 1.7 you can provide multiple cookiecutters in separate directories. Right now we have a few styles of repos:

  • platform
  • plugins
  • tools

Creating multiple cookiecutters for each style would make the cookiecutter much more flexible to use.

Note: shared files can be included across directories with soft links.

Updates

  • update actions versions in template files
  • automate ^
  • update python-requires and classifiers to drop 3.8 and add 3.12
  • readme doesn't need to be dynamic
  • script runner arguments

Move away from `console_script` entrypoints

Inthe past, we've created command line (console-script) entrypoints for hyp3 plugins, making a "hyp3" entry point(s), and a "science" entry point which has more available options. For example, in hyp3-gamma:

For this cookiecutter:

  1. we don't need to register any HyP3 console script entry points as the hyp3 entry points are already accessible on the command line via python -m
  2. we don't need to register extra "science" entry points as this is a cookie cutter intended to help you develop a hyp3-plugin, and not every plugin will need a CLI version of the "science" code (e.g., "scientists" may prefer jupyter notebooks and not use the command line at all)

Accordingly, I believe we can:

Will the package be created automatically with correct permissions?

While creating the https://github.com/ASFHyP3/hyp3-isce2 plugin, we ran into an issue where the GitHub package had already been created and did not have correct permissions set to allow the build workflow to push the Docker image, see here: ASFHyP3/hyp3-isce2#3 (comment)

I want to know if everything would have worked if the package had not already been created; would the package be created automatically with the correct permissions? If not, we should document the steps for setting the correct perms.

Plugin creation issue collection

This is an issue where I'm recording issues I ran into while using the version of the cookiecutter currently in update-staging. I'll expand this into more actionable issues if necessary.

Need to update Actions

Prior to creation of the ISCE2 plugin, we would like to update the GitHub Actions to the latest version. Here is a list of all the reusable actions from ASFHyP3/actions:

  • reusable-bump-version.yml
  • reusable-changelog-check.yml
  • reusable-docker-ghcr.yml
  • reusable-flake8.yml
  • reusable-labeled-pr-check.yml
  • reusable-pytest.yml
  • reusable-release-checklist-comment.yml
  • reusable-release.yml
  • reusable-secrets-analysis.yml
  • dependabot.yml

Need better documentation on how to set permissions for `GITHUB_PAK`

In order to get the CI/CD working correctly, the user of the cookiecutter will need to create a Personal Access Token with a certain set of permissions. We should document:

  1. Which type of access token they should create (Classic or Fine-Grained) - I believe the answer is Classic?
  2. What is the minimal set of boxes in the screenshot below that need to be checked in order for the actions to work?

Screen Shot 2023-03-20 at 9 25 51 AM

Do we want to switch to cookieninja?

The cookiecutter project has not had any substantial development in at least the last 9 months. As such, someone forked-off cookieninja as described in this cookiecutter issue: cookiecutter/cookiecutter#1810

There appears to be some cookiecutter maintainer drama, and they have pinned the cookieninja to the top of the cookiecutter issues queue, but have not officially responded in any way.

We should consider switching to Cookieninja if it does appear to be actively maintained and developed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.