-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI setup for a package #72
Comments
it just occurred to me that a cron job maybe monthly or biweekly could be good if you have a lot of deps and things aren't pinned (which normally they wouldn't be). but that still could be triggered in the tests ci run along with the pr / commit trigger! |
I use cron jobs on my packages exactly for that purpose, it helps me discover when a new release of a dependency breaks my package. (Or at least my test suite 😉.) The reason that I decided for a separate file is that the tests themselves have a trigger on being called. So it is straight forward to use the test suite in different scenarios. You are correct that the cron schedule could be added as a trigger instead of using a separate file. |
@Midnighter this is all really good to think through. My main concern right now, is not that the workflows aren't robust!! they are and your point above made me realize I might want to update some things on the package I work on!! 🚀 here, however, I'm worried that there is some complexity in the setup of things that might cause additional cognitive load for those newer to packaging. ie in this case running CI builds as workflows - Let's imagine that someone is new to CI and tries to figure out what the template creates. And i'm trying to see if we can find a middle ground where we're providing a template that has good enough best practices while still being somewhat new-to-packaging friendly. We can also have documentation / tutorials on adding layers as well if we want to. What do you (and others?!) think about having documentation around how to setup a job as a reusable workflow but not actually implementing this in our template to keep things simpler? But we keep the cron job. |
Those are very good points 🙂. I tend to get carried away by exciting new features that I discover 😉. I agree, let's keep workflows simple. Whether we want to document reusable workflows at all, I'm not sure. They are certainly not needed to be successful with Python packaging. |
I am going to submit a pr related to this.
it seems like we have some additional elements that we might not need for beginners in this template.
currently the workflows including a test cron job that runs weekly that calls the test workflow.
I'd suggest we move away from extra builds for now and talk about possibilities without including everything in our template. this will make the entry simpler for users.
i am going to submit a pr that removes those two jobs and adds a released base publish to PyPI workflow.
The text was updated successfully, but these errors were encountered: