monasca / pr-bot Goto Github PK
View Code? Open in Web Editor NEWAutomatic version checker bot
License: Apache License 2.0
Automatic version checker bot
License: Apache License 2.0
Currently new and removed modules aren't detected when softUpdateRepositories
is run. This should, eh, happen.
The bot tries to auto-detect as much as possible, but this isn't always feasible. It should be possible to store per-repository and per-module configuration in git to specify various options:
Something like http://mozilla.github.io/nunjucks/templating.html would be useful here.
Version tags (especially for Docker images) often contain additional metadata about that entry in the repository. In most cases (at least that we care about) these are usually dash-separated tokens in the version, like python:3.6-alpine3.6
.
In general we shouldn't automatically propose updates that would switch between different tags or "release trains". As an example, the bot generated an update to monasca-helm: monasca/monasca-helm#185
In this case monasca-helm's client chart is using "released" image versions with standard semver tags (monasca/client:1.6.0
- we'd probably consider this a null
tag) and the bot tried to update it to use monasca/client:master-20170918-185757
(master
tag). Since monasca/client:1.7.0
was also published we should have used that release instead.
This introduces some problems:
semver-patch
: only update z
in x.y.z
semver-minor
: either y
or z
in x.y.z
semver-major
: always use latest available semversemver-*
could have additional policy options:
tagPolicy
: sticky
(default) only updates to matching tags (e.g. no updates to master
from null
), none
ignores tags (current behavior)tag
: just lock to a particular tagdatever
: (or something) use the tag with the latest embedded timestamp (for the master-{date}-{time}
case)last-published
: current behaviorWe should have some ability to retry failed actions (say, HipChat notification timeouts) and - more generally - run tasks on a timer.
GCF doesn't have a good way to do this, unfortunately. We'll need to roll our own to some degree.
Support for plain Docker registries should be added. Right now dockerhub
repositories determine current image versions using APIs only available from hub.docker.com.
At a minimum we need to support private docker registries (running https://hub.docker.com/_/registry/). This is (very) partially implemented now but needs to be finished. Current version detection will be somewhat worse.
There's also Docker Trusted Registry. It exposes a few more API functions and may be able to return timestamped tags. If the APIs match those on hub.docker.com we can add it to that plugin, otherwise it will need its own.
Consider supporting tracking and updating glide.yaml
and glide.lock
With release plugins (#9) and repository hooks (#19) we have a decent story for managing the whole CI/CD process, at least on the backend. However, we still need to give users control over how and when a change is is built and released. Ideally this should integrate directly with GitHub issues/pull requests and we should avoid having any external UI.
One idea is for the bot to detect changed modules in a particular PR. It can then leave a comment on the PR users can interact with. Examples in followup comments.
(extracted from #15 (comment))
Since the PR bot is handling GitHub hooks anyway, it could be a convenient way to add repo-specific event handlers. In addition to repository and module specific configuration (#15), we could also let users drop in .js scripts:
Some thoughts:
.bot/hooks/pull_request.js
: runs on a PullRequestEvent
push
label in monasca-docker.bot/hooks/status.js
: runs on a StatusEvent
We may want to execute these hooks in a sandboxed context, like vm2.
Flat git repositories should be supported (as per
Line 305 in afdf55a
'flat' in this case would mean a single module in a repository, presumably not in a subdirectory. Most single-project repositories (not like monasca-docker) are built like this, including the pr-bot repo itself.
Right now our HipChat notifications are very noisy. As an example, we just merged monasca/monasca-docker#322. This caused:
push
, pr
)push
, pr
)push
)push
, pr
)pr
) for Travis status update to monasca-helm for auto-update PR (no push
since the bot commits to a fork)So 1 change through the pipeline generated 11 notification cards in our HipChat room.
Issues with this include:
kafka-init
module due to #14 - so actually it should've been 12 notifications!push
events (continuous-integration/travis-ci/push
context)Minimally I'd like to see the following messages:
It would also be nice to use collapsed cards for all non-error messages. Link directly to the PR via the title and keep the details hidden.
For the above example this would cut it down to 8-9 messages. To be honest this is still too many, but I'm not sure how to cut this down more. At least we can make the messages we do send actually helpful so there's a reason to read them.
It would be nice if we could include a summary of commits between versions in auto-generated PRs. Probably just a bulleted list of commit message titles between versions.
latest
can be treated as the "recommended promoted artifact", so when possible we should try to use any other (more specific) tags that resolve to the same hash.
Since many tags can refer to the same hash, we'll need some heuristic to decide which is the best / most unique. It may sound dumb, but string length might be a good metric. Otherwise we'd need to use a regex to find timestamps or something.
Per https://issuetracker.google.com/issues/36252545, GCF now provides access to the raw request body, meaning we can securely validate webhooks from GitHub in more or less the same way that we validate for standalone. We can remove the 2nd webhook now.
The bot will make a branch in its fork for every update. These build up quite a bit over time (monasca-ci has 88 old branches now). It would be nice if branches were automatically deleted when a PR is closed.
The bot should leave a warning (maybe as a comment on the pull request) when the existing version doesn't match the fromVersion
from the Update instance. In most cases this is probably fine, but it'd be good to know to take a closer look at the patch before applying (in case a dependency isn't recognized quite correctly).
.drone.yml
can depend on docker images which we could track and update.
The main complication is that drone projects that use secrets require a .drone.yml.sig
which the bot will not be able to update.
.drone.yml
?Right now the bot doesn't care if dependencies stay out of date for a long time. For instance, if a dependency reference is already out of date when the bot is initialized it will never file a PR despite the version mismatch, and if a generated PR is closed or never merged it just assumes that it's up-to-date.
The bot can take a few actions to improve the UX:
(depends on #2 to check for updates intermittently and parts of #8 since PRs would actually need to be tracked properly)
The last ... many ... updates to several modules in monasca-helm always show the fromVersion
of e.g. kafka as being 0.2.0
. For some reason we only generate updates when new versions are actually pushed
I've also confirmed that the database version is stuck at 0.2.0
so it isn't some odd template rendering bug or anything like that.
The bot filed monasca/monasca-helm#182 automatically, but the same upgrade was merged manually in monasca/monasca-helm#183.
We should be able to detect this case and close existing PRs. Presumably requires #8.
A small webpage to show tracked repositories, modules, versions, and dependencies would be very helpful. With authentication it could even be used to manually trigger updates, releases, etc.
It would be trivial to serve a page via the express server. For GCF we'd need a different solution but it would probably just be a static page that makes API calls (so a GCP bucket). We would probably want to remove authentication from read-only endpoints, though. Also, we'll need some CORS rules.
A tool like this would be a big help for debugging issues like #14 and #22.
It would be extremely useful to have some support for repository subsetting. Right now we track all modules in a given repository, but this would be bad behavior for things like e.g. the public Helm repo. It would be nice if we could only check for updates to the modules from these repositories that we care about (or that have some reverse dependency relationship)
Probably depends on #2 since we'll only want to update these repositories every 24 hours or so.
It would be nice to have (in addition to mutation/update plugin) support for release plugin. These would perform whatever tasks are needed to release a new version. Some examples:
!push <module>
in the commit messageIt'd be nice to use the pr bot to send notification on CI/CD pass / fail for pull requests. Unfortunately status events don't include any details about their associated pull request and only have the commit sha. To send notifications properly, we'll need to keep tracked PRs and their hashes in the database.
Realistically this means fleshing out https://github.com/monasca/pr-bot/blob/master/lib/pullrequest.js more fully.
Right now we only support HipChat which is less than ideal.
js-yaml changes the formatting from what helm outputs by default. Pretty minor, but would be nice.
(yawn-yaml will be included already since it's being used for values.yaml
modifications)
When available, https://cloud.google.com/pubsub/docs/ should be used to deliver notifications. HipChat servers are often slow to respond and can time out. PubSub would decouple notification failures from an otherwise successful action, and help to ensure delivery since we could then retry.
Also, when we don't need to run shell commands, we can use much smaller functions. A 256 MiB function can run for 60 seconds waiting on a slow HipChat endpoint at 1/8th the cost of our main function.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.