gateTools
From Genunix
Contents |
Tool Status
| Tool | Technical Notes | Owner | Start Date | Time Estimate | Completion Date | Status Notes |
| add-gateling | Goes away; gatelings self-subscribe to a list | Done in that it is not being ported or otherwise made to work with Mercurial | ||||
| biweekly_build | Done | |||||
| clone_update | Needed for SFW. Can this become 'hg pull'? | |||||
| daily_snapshot | ||||||
| pbcheck | Ideally, all checks should run before putback. Currently doesn't have all the checks we eventually want. | |||||
| pbconfirm | ||||||
| ping-docbugs | ||||||
| post_biweekly_build | ||||||
| process_build_mail | ||||||
| putback_diffs | goes away? | |||||
| update_SUNWonbld | ||||||
| update_flagdays |
| Tool | Technical Notes | Owner | Start Date | Time Estimate | Completion Date | Status Notes |
| backout | hg backout --merge | Done: achieve by using 'hg backout --merge' | ||||
| bug_update | ||||||
| buglist | Done | |||||
| copy_build | ||||||
| copy_respin_build | ||||||
| docimpact | Done | |||||
| increment_build | ||||||
| lock-gate | is the webapp's lock switch sufficient? | Done | ||||
| pre-mkdelivery | ||||||
| rfelist | Done | |||||
| rtcgen | For SFW, needs to parse putback log looking for new packages. NOTE: SFW and ON each have their own version. | Done | ||||
| unlock-gate | see lock-gate | Done | ||||
| which-build |
Go back to SCMMigrationTasks
To Do
workflow
We need to resolve some questions about workflow: how much do we emulate current the current gate tools and how much do we change to use native Mercurial facilities.
For example, do we keep the text putback log, for tools like rtcgen, or do we use "hg log" output? Note that the ON gatekeepers sometimes edit the putback log, e.g., to correct putback comments.
enforcement hooks
We've been talking about using gate-side hooks to enforce certain things like cstyle. That is, changesets that fail the tests would be prevented from pushing to the gate. This is a change from current practice, where issues are usually dealt with by follow-on putbacks or manual backout/undo.
We need to decide if there are any issues that absolutely must be handled by an enforcement hook, or if all issues can be handled by follow-on changesets or manual backout.
The ON Teamware gate has a bunch of check scripts that run for each putback--reviewing those checks is probably sufficient (we probably don't need to think up more checks).
Having an approved RTI seems like a good candidate for an enforcement check, though we'll probably want some sort of backdoor for gatekeepers.
hook details
Break up the hooks table into two pieces, one for things that will actually be run from Mercurial hooks, and one for things that will be run from cron.
For the actual hooks, specify which Mercurial hook will be used (changegroup, incoming, etc).
dependencies
Figure out and document dependencies that the hooks/tools will have (e.g., RTI database, OpenSolaris user database, files created by other tools). For example, pbconfirm should send mail to the user doing the push, not the users who committed the changesets. This will require getting the user's email address from the os.o user database.
Other Notes
build snapshots
The current plan is for each build snapshot to live in its own repo (rather than being a branch in the gate). This is largely because we (and our tools) already understand that model.
The bad news is that we don't yet have an easy way to fork off a snapshot workspace. This could either be something in the webapp, or a script. If it's a script, the gatekeeper will need shell access to the os.o servers. Note that we've been asked to make it easier for project owners to create repositories via a local clone (CR 6502732); we could probably use the same infrastructure for snapshot workspaces.
References
- additional gate architecture notes.
- Description of existing tools.
