-
Notifications
You must be signed in to change notification settings - Fork 7
Contribute
As of 2022-02-16 this is our plans, listed somewhat by priority (which often changes without warning).
- Adding bearer token-based authentication.
- Adding brew support.
- Document our workflows for ourselves.
- Integrate Python Black in our workflow.
- Fix bugs in pkgctl.
- Sort package versions correctly.
- Add a new tool that works with AutoPkg.
- Add a new tool that updates the package associated with a policy, group, patch, enrollment, SS description, etc. that have certain criteria (name, scope, category, SS description, etc).
- Add new policies, patch, groups, whatever based on a criteria found in new AutoPkg packages (similar to what JSSImporter does).
- Add a new tool that uses regex to synchronize "stages". That is, if you have policies, groups, patch, enrollment, SS description, etc. that match a name, scope, category, or SS description regex (like name contains "testing") then synchronize all of those with another set with a different regex (like name contains "production").
- Make pkgctl more useful.
- Add jctl subcommands that are useful.
- Move patch.py functionality elsewhere and remove that script.
- Come up with a better way to deal with arrays.
- Fix unit testing.
- Improve how data is printed.
- Upload packages (maybe using jamf-upload).
- Identify unused packages, scripts, policies and optionally remove them (including archiving packages), similar to other Jamf cleanup scripts.
- Print record path hierarchy without the actual data (will help understanding and using jctl).
- Add glob/wildcard to paths (e.g.
jctl computers -p general/*/10.10.0.0). - Add feature similar to Scriptorium.
- Add UAPI support and see what we can do with it.
- Sam Forester
- James Reynolds
- Topher Nadauld
- Richard Glaser
- Tony Williams
- O'Ryan Hampton
There are multiple ways you can contribute to this project, depending on your technical expertise with git, Github, Python, or Jamf Pro. Anything could have value and improve the project for the community from code, documentation, feature requests, reporting bugs, etc.
Please reach out to us however you can. We have the jctl channel on the the MacAdmins Slack server or you can create an issue if you can't find our contact info some other way.
We meet once a week for a few hours during regular work hours. We don't get much done usually, but it keeps us thinking about it and every python-jamfonce and a while someone spends a lot of extra personal time pushing the project forward. That's how we got here. If you'd like to join, please reach out to us.
Here is a list of help that can be contributed by community.
- Real World Usage Workflow
Quick documentation outlining real world usage & benefits of the tools to Jamf Pro administrators new to our projects.
- Human Readable Descriptions of Jamf Records
Would like a human readable description of the Jamf records included in the project. To make it easier to discover and understand what a specific jamf record does or doesn't do.
GitHub currently dosen't support wiki pull requests, so the best route is to open an issue and include the documentation addition or correction.
If you would like to contribute by coding Python, one way to get started is to first install and run jctl in Docker. This allows you to work on the code in an isolated environment.
At this point we will try to integrate any code if we can understand it and it doesn't take too much of our time to integrate it. Pull requests are welcome too if you want to follow the The Github Code Contribution Lifecycle described below.
Forking the repository creates a copy of it in your GitHub account. In your account, you can make changes and push any code to this fork, without worrying about messing up our original codebase.
The forked repository will now be available in the “Repositories” section of your account.
Now you need to clone the forked repository to your machine so that we have a local copy of our code. Click on the clipboard icon next to the SSH or HTTPS URL of your forked repository to copy it.
pre-commit is a framework that automatically runs linting and consistency checks before changes are committed to the repository locally. For contributors who will be working in Python code, we recommend installing pre-commit and running pre-commit install in the repo to activate these checks.
For more information about pre-commit see the following developer website. Or view this presentation on "Intro to Pre-Commit" (video) (slides) at the 2019 University of Utah, MacAdmin meeting by Elliot Jordan.
While making any change to the code, a best practice is to create a new feature branch for the changes you need to make. This ensures that we keep the master branch clean, and can simply revert our code or make updates when necessary.
Switch to the directory that was created after you cloned the forked repository.
Create a new feature branch with the name that identifies the changes you are planning to add or change.
If you have created any new files as part of your change, you will need to add them to the branch you just created.
For all the changes made, you have to commit them to the branch. Make sure you add a valid & descriptive commit message.
Push your commit to your forked repository.
Once you have pushed your code to your forked repository, it's time to raise a pull request (PF) against our main code repository.
Click on the “Pull Request” button to start a new PR.