Skip to content
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

Allow Builder to ignore certain files when responding to Github webhooks #5143

Open
christophermaier opened this issue Jun 1, 2018 · 4 comments
Labels
Documentation Flags an issue / PR for attention by the technical documentation team Stale Type: Feature Issues that describe a new desired feature

Comments

@christophermaier
Copy link
Contributor

christophermaier commented Jun 1, 2018

Currently, you can specify fileglobs in .bldr.toml what determine when to trigger a build; if a changed file matches the glob, build.

Sometimes, though, it can be useful to specify the inverse. A commit that consists of only a README change, for example, shouldn't be creating a new package.

We should have a way to express this in .bldr.toml

@baumanj
Copy link
Contributor

baumanj commented Jun 1, 2018

Would we prefer to make everything explicit, or would an implicit (but overridable) policy of never triggering for changes to certain globs such as *.md be good?

I figure that might avoid a lot of unnecessary work without requiring as much configuration effort for each builder package.

@reset
Copy link
Collaborator

reset commented Jun 1, 2018

I think it's a little bit too "magic" that somebody would need to know what the default whitelist is. I wouldn't want to be on the receiving end of trying to debug a build that isn't triggering because content that is inlined into my code but stored as an .md.

It'd be perfectly reasonable to include a default whitelist in a generated .bldr.toml for somebody, though!

@stale
Copy link

stale bot commented Apr 3, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

@stale stale bot added the Stale label Apr 3, 2020
@christophermaier christophermaier added Type: Feature Issues that describe a new desired feature and removed C-feature labels Jul 24, 2020
@stale stale bot removed the Stale label Jul 24, 2020
@christophermaier christophermaier added Documentation Flags an issue / PR for attention by the technical documentation team and removed A-documentation labels Aug 18, 2020
@stale
Copy link

stale bot commented Aug 12, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

@stale stale bot added the Stale label Aug 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation Flags an issue / PR for attention by the technical documentation team Stale Type: Feature Issues that describe a new desired feature
Projects
None yet
Development

No branches or pull requests

4 participants