-
Notifications
You must be signed in to change notification settings - Fork 21
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
Disable weekly updates #1270
Disable weekly updates #1270
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make it a bit easier to properly uncomment this in the future.
Co-authored-by: Roni Choudhury <2903332+waxlamp@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be a merge from main or is it better to rebase here?
I don't think it matters as it gets into main because it will be a squash anyways, so only the changes get committed into main. So in the overall git history it will look like a single commit. If you take a look into the PR for 1.9 and activity groups getting added in there are lot of merges of main into the branch, but the history only has a single commit with the changes. It means we don't have to be exact with our development process or clean up the git history before we merge the PR, but we still retain a history of what occurred within the individual PR. There are probably good arguments for doing it the opposite as well. |
This leaves the watchtower container running but prevents it from doing the weekly update on the girder/girder-worker containers. This was request to prevent it from updating weekly like this.
https://containrrr.dev/watchtower/arguments/#filter_by_enable_label
That should provide some information on why I commented out the label in the docker-compose.yml