2016-03-25 21:55:34 +00:00
|
|
|
'use strict';
|
|
|
|
|
2016-06-06 18:51:23 +00:00
|
|
|
const assert = require('assert');
|
2016-03-25 21:55:34 +00:00
|
|
|
|
|
|
|
require('../tools/js/v3-models.js');
|
|
|
|
|
2016-06-06 18:51:23 +00:00
|
|
|
const MockData = require('./resources/mock-data.js');
|
|
|
|
const TestServer = require('./resources/test-server.js');
|
2017-03-15 03:19:02 +00:00
|
|
|
const prepareServerTest = require('./resources/common-operations.js').prepareServerTest;
|
2016-03-25 21:55:34 +00:00
|
|
|
|
2016-03-31 04:18:39 +00:00
|
|
|
describe('/api/manifest', function () {
|
2017-03-15 03:19:02 +00:00
|
|
|
prepareServerTest(this);
|
2016-03-25 21:55:34 +00:00
|
|
|
|
2017-03-15 03:19:02 +00:00
|
|
|
it("should generate an empty manifest when database is empty", () => {
|
|
|
|
return TestServer.remoteAPI().getJSON('/api/manifest').then((manifest) => {
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(Object.keys(manifest).sort(), ['all', 'bugTrackers', 'builders', 'dashboard', 'dashboards',
|
2020-12-09 23:13:28 +00:00
|
|
|
'fileUploadSizeLimit', 'maxRootReuseAgeInDays', 'metrics', 'platformGroups', 'repositories', 'siteTitle',
|
|
|
|
'status', 'summaryPages', 'testAgeToleranceInHours', 'tests', 'triggerables']);
|
2016-03-25 21:55:34 +00:00
|
|
|
|
2016-10-18 22:22:55 +00:00
|
|
|
assert.deepStrictEqual(manifest, {
|
2016-03-25 21:55:34 +00:00
|
|
|
siteTitle: TestServer.testConfig().siteTitle,
|
|
|
|
all: {},
|
|
|
|
bugTrackers: {},
|
|
|
|
builders: {},
|
|
|
|
dashboard: {},
|
|
|
|
dashboards: {},
|
2017-03-16 20:53:35 +00:00
|
|
|
fileUploadSizeLimit: 2097152, // 2MB during testing.
|
2020-12-09 23:13:28 +00:00
|
|
|
maxRootReuseAgeInDays: null,
|
2016-03-25 21:55:34 +00:00
|
|
|
metrics: {},
|
2020-10-28 01:00:35 +00:00
|
|
|
platformGroups: {},
|
2016-03-25 21:55:34 +00:00
|
|
|
repositories: {},
|
2017-12-14 09:49:37 +00:00
|
|
|
testAgeToleranceInHours: null,
|
2016-03-25 21:55:34 +00:00
|
|
|
tests: {},
|
2017-01-12 07:18:28 +00:00
|
|
|
triggerables: {},
|
2016-10-18 22:22:55 +00:00
|
|
|
summaryPages: [],
|
2016-03-25 21:55:34 +00:00
|
|
|
status: 'OK'
|
|
|
|
});
|
2017-03-15 03:19:02 +00:00
|
|
|
});
|
2016-03-25 21:55:34 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
const bugzillaData = {id: 1, name: 'Bugzilla', bug_url: 'https://webkit.org/b/$number', new_bug_url: 'https://bugs.webkit.org/'};
|
|
|
|
const radarData = {id: 2, name: 'Radar'};
|
|
|
|
|
2017-03-15 03:19:02 +00:00
|
|
|
it("should generate manifest with bug trackers without repositories", () => {
|
|
|
|
return TestServer.database().insert('bug_trackers', bugzillaData).then(() => {
|
2016-03-30 03:16:29 +00:00
|
|
|
return TestServer.remoteAPI().getJSON('/api/manifest');
|
2017-03-15 03:19:02 +00:00
|
|
|
}).then((content) => {
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(content.bugTrackers, {1: {name: 'Bugzilla', bugUrl: 'https://webkit.org/b/$number',
|
2016-03-25 21:55:34 +00:00
|
|
|
newBugUrl: 'https://bugs.webkit.org/', repositories: null}});
|
|
|
|
|
|
|
|
let manifest = Manifest._didFetchManifest(content);
|
|
|
|
let tracker = BugTracker.findById(1);
|
|
|
|
assert(tracker);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(tracker.name(), 'Bugzilla');
|
|
|
|
assert.strictEqual(tracker.bugUrl(123), 'https://webkit.org/b/123');
|
|
|
|
assert.strictEqual(tracker.newBugUrl(), 'https://bugs.webkit.org/');
|
2017-03-15 03:19:02 +00:00
|
|
|
});
|
2016-03-25 21:55:34 +00:00
|
|
|
});
|
|
|
|
|
2018-07-03 03:55:24 +00:00
|
|
|
it("should clear Bug and BugTracker static maps when reset", async () => {
|
|
|
|
await TestServer.database().insert('bug_trackers', bugzillaData);
|
|
|
|
const content = await TestServer.remoteAPI().getJSON('/api/manifest');
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(content.bugTrackers, {1: {name: 'Bugzilla', bugUrl: 'https://webkit.org/b/$number',
|
2018-07-03 03:55:24 +00:00
|
|
|
newBugUrl: 'https://bugs.webkit.org/', repositories: null}});
|
|
|
|
|
|
|
|
Manifest._didFetchManifest(content);
|
|
|
|
const trackerFromFirstFetch = BugTracker.findById(1);
|
|
|
|
|
|
|
|
Manifest.reset();
|
|
|
|
assert(!BugTracker.findById(1));
|
|
|
|
|
|
|
|
Manifest._didFetchManifest(content);
|
|
|
|
const trackerFromSecondFetch = BugTracker.findById(1);
|
|
|
|
assert(trackerFromFirstFetch != trackerFromSecondFetch);
|
|
|
|
});
|
|
|
|
|
2017-03-15 03:19:02 +00:00
|
|
|
it("should generate manifest with bug trackers and repositories", () => {
|
2016-03-25 21:55:34 +00:00
|
|
|
let db = TestServer.database();
|
2017-03-15 03:19:02 +00:00
|
|
|
return Promise.all([
|
2016-03-25 21:55:34 +00:00
|
|
|
db.insert('bug_trackers', bugzillaData),
|
|
|
|
db.insert('bug_trackers', radarData),
|
|
|
|
db.insert('repositories', {id: 11, name: 'WebKit', url: 'https://trac.webkit.org/$1'}),
|
Each build request should be associated with a repository group
https://bugs.webkit.org/show_bug.cgi?id=170528
Rubber-stamped by Chris Dumez.
Make the buildbot syncing script use the concept of repository groups so that each repository group can post
a different set of properties to buildbot. In order to do this, we associate each build request with
a repository group to use. Each triggerable's repository groups is now updated by the syncing scripts via
/api/update-triggerable just the same way the set of the supported platform, test pairs are updated.
Each repository group specifies the list of repositories, a dictionary that maps the buildbot property name
to either a string value or a repository name enclosed in < and >:
```js
"repositoryGroups": {
"webkit-svn": {
"repositories": ["WebKit", "macOS"],
"properties": {"os": "<macOS>", "wk": "<WebKit>"}
}
}
```
With this, removed the support for specifying a repository to use in generic dictionary of properties via
a dictionary with a single key of "root", "rootOptions", and "rootsExcluding". We now validate that the list of
repositories in each repository group matches exactly the ones used in buildbot properties as well as ones in
build requests.
After this patch, sync-with-buildbot.js will no longer schedule a build request without a repository group.
Run the appropriate database queries to set the repository group on each build request. Because of this change,
this patch also makes BuildbotTriggerable.prototype.syncOnce more robust against invalid build requests.
Instead of throwing an exception and exiting early, it simply skips all build requests that belong to the same
test group if the next build request to be scheduled does not specify a repository group.
* init-database.sql: Add request_repository_group column to build_requests table, and a unique constraint for
repository and group pair in triggerable_repositories table.
* public/api/update-triggerable.php:
(main): Validate and insert repository groups.
(validate_configurations): Extracted from main.
(validate_repository_groups): Added.
* public/v3/models/repository.js:
(Repository.findTopLevelByName): Added.
* public/include/build-requests-fetcher.php:
(BuildRequestsFetcher::results_internal): Include the repository group of each request in the JSON response.
* public/include/repository-group-finder.php: Added. A helper class to find the repository group for a given
triggerable for a list of repositories.
(RepositoryGroupFinder): Added.
(RepositoryGroupFinder::__construct): Added.
(RepositoryGroupFinder::find_by_repositories): Added.
(RepositoryGroupFinder::populate_map): Added.
* public/privileged-api/create-test-group.php:
(main): Each element in an array returned by ensure_commit_sets and commit_sets_from_revision_sets now contains
"set", the list of commit IDs, and "repository_group", the repository group identified for each commit set.
Use that to set the repository group in each new build request.
(commit_sets_from_revision_sets): Use RepositoryGroupFinder to find the right repository group.
(ensure_commit_sets): Ditto. There is no need to find a repository group for each commit set here since its
argument is keyed by the repository name. e.g. {"WebKit": [123, 456], "macOS": ["16A323", "16A323"]}
* public/v3/models/build-request.js:
(BuildRequest):
(BuildRequest.prototype.triggerable): Added.
(BuildRequest.prototype.repositoryGroup): Added.
(BuildRequest.constructBuildRequestsFromData): Resolve the triggerable and the repository group.
* public/v3/models/triggerable.js:
(Triggerable.prototype.name): Added.
(Triggerable.prototype.acceptedRepositories): Deleted.
(TriggerableRepositoryGroup):
(TriggerableRepositoryGroup.prototype.accepts): Added. Retruns true if the repository group
* server-tests/api-build-requests-tests.js: Added a test for getting the repository group of a build request.
* server-tests/api-manifest-tests.js: Added assertions for the repository groups.
* server-tests/api-report-tests.js:
(.emptyReport):
(.reportWithTwoLevelsOfAggregations):
* server-tests/api-update-triggerable.js: Added test cases for updating the repository groups associated with
a triggerable.
(.updateWithOSXRepositoryGroup):
(.mapRepositoriesByGroup):
* server-tests/privileged-api-create-test-group-tests.js:
(addTriggerableAndCreateTask): Add two repository groups for testing. Added assertions for repository groups
in existing test cases, and added a test case for creating a test group with two different repository groups.
* server-tests/resources/mock-data.js:
(MockData.resetV3Models): Reset TriggerableRepositoryGroup's static maps.
(MockData.emptyTriggeragbleId): Added.
(MockData.macosRepositoryId): Added.
(MockData.webkitRepositoryId): Added.
(MockData.gitWebkitRepositoryId): Added.
(MockData.addMockData): Create repository groups as needed. Renamed the "OS X" repository to "macOS" since some
tests were using the latter, and now we need mock data to be consistent across tests due to stricter checks.
(MockData.addEmptyTriggerable): Added. Used in api-update-triggerable.js.
(MockData.addMockTestGroupWithGitWebKit): Added. Used in api-build-requests-tests.js.
(MockData.addAnotherMockTestGroup): Cleanup.
(MockData.mockTestSyncConfigWithSingleBuilder): Updated the mock configuration per code changes.
(MockData.mockTestSyncConfigWithTwoBuilders): Ditto.
* server-tests/tools-buildbot-triggerable-tests.js: Updated a test case testing /api/update-triggerable to test
updating the set of repository groups in addition to the set of test, platform pairs.
(.refetchManifest): Added.
* tools/js/buildbot-syncer.js:
(BuildbotSyncer): Now takes a set of configurations shared across syncers: repositoryGroups, slaveArgument,
and buildRequestArgument as the third argument.
(BuildbotSyncer.prototype.repositoryGroups): Added.
(BuildbotSyncer.prototype._testGroupMapForBuildRequests): Cleaned up the code to use Array.prototype.find.
Also added an assertion that the build request is associated with a repository group.
(BuildbotSyncer.prototype._propertiesForBuildRequest): Removed the support for using an arbitary property to
specify a revision in favor of explicity listing each property and repository name in a repository group.
(BuildbotSyncer._loadConfig): Removed the support for "shared", which specified the set of buildbot properties
shared across syncers, the name of properties which specifies the build slave name and build request ID. These
values are not stored as top-level properties and superseded by the concept of repository groups.
(BuildbotSyncer._parseRepositoryGroup): Parses and validates repository groups.
(BuildbotSyncer._createTestConfiguration): We no longer expect each configuration to specify a dictionary of
properties or buildRequestArgument (often inherited from shared).
(BuildbotSyncer._validateAndMergeConfig): Removed "slaveArgument" and "buildRequestArgument" from the list of
allowed proeprties in each configuration now that they're specified as top-level properties.
* tools/js/buildbot-triggerable.js:
(BuildbotTriggerable.prototype.updateTriggerable): Update the associated repository groups.
(BuildbotTriggerable.prototype.syncOnce): Skip test groups for which the next build request to be scheduled is
not included in the list of valid build requests.
(BuildbotTriggerable.prototype._validateRequests): Now returns the list of valid build requests, which excludes
those that lack a repository group set.
(BuildbotTriggerable.prototype._nextRequestInGroup): Extracted from _scheduleRequestIfSlaveIsAvailable. Finds
the next build request to be scheduled for the test group.
(BuildbotTriggerable.prototype._scheduleRequestIfSlaveIsAvailable): Renamed from
_scheduleNextRequestInGroupIfSlaveIsAvailable. Now takes the syncer and the slave name as arguments instead of
a test group information since syncOnce now calls _nextRequestInGroup to find the next build request.
* tools/js/v3-models.js:
* unit-tests/build-request-tests.js: Fixed the test name.
* unit-tests/buildbot-syncer-tests.js: Removed tests for "rootOptions" and "rootsExcluding", and added tests
for parsing repository groups.
(sampleiOSConfig): Updated the mock configuration per code changes.
(sampleiOSConfigWithExpansions): Ditto.
(smallConfiguration): Ditto. Now returns the entire configuration instead of a single builder configuration.
Various test cases have been updated to reflect this.
(createSampleBuildRequest): Removed the git hash of WebKit to match the repository groups listed in the mock
configurations. The git hash was there to test "rootOptions", which this patch removed.
(samplePendingBuild): Removed "root_dict" from the list of properties. This was used to test "rootsExcluding"
which, again, this patch removed.
(sampleInProgressBuild): Ditto.
(sampleFinishedBuild): Ditto.
* unit-tests/resources/mock-v3-models.js:
(MockModels.inject): Added ock repository groups so that existing tests will continue to function.
Canonical link: https://commits.webkit.org/187490@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@215061 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-06 21:56:59 +00:00
|
|
|
db.insert('repositories', {id: 9, name: 'macOS'}),
|
2016-03-25 21:55:34 +00:00
|
|
|
db.insert('repositories', {id: 22, name: 'iOS'}),
|
|
|
|
db.insert('tracker_repositories', {tracker: bugzillaData.id, repository: 11}),
|
|
|
|
db.insert('tracker_repositories', {tracker: radarData.id, repository: 9}),
|
|
|
|
db.insert('tracker_repositories', {tracker: radarData.id, repository: 22}),
|
2017-03-15 03:19:02 +00:00
|
|
|
]).then(() => {
|
2016-03-30 03:16:29 +00:00
|
|
|
return TestServer.remoteAPI().getJSON('/api/manifest');
|
2017-03-15 03:19:02 +00:00
|
|
|
}).then((content) => {
|
2016-03-25 21:55:34 +00:00
|
|
|
let manifest = Manifest._didFetchManifest(content);
|
|
|
|
|
|
|
|
let webkit = Repository.findById(11);
|
|
|
|
assert(webkit);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(webkit.name(), 'WebKit');
|
|
|
|
assert.strictEqual(webkit.urlForRevision(123), 'https://trac.webkit.org/123');
|
2016-03-25 21:55:34 +00:00
|
|
|
|
Each build request should be associated with a repository group
https://bugs.webkit.org/show_bug.cgi?id=170528
Rubber-stamped by Chris Dumez.
Make the buildbot syncing script use the concept of repository groups so that each repository group can post
a different set of properties to buildbot. In order to do this, we associate each build request with
a repository group to use. Each triggerable's repository groups is now updated by the syncing scripts via
/api/update-triggerable just the same way the set of the supported platform, test pairs are updated.
Each repository group specifies the list of repositories, a dictionary that maps the buildbot property name
to either a string value or a repository name enclosed in < and >:
```js
"repositoryGroups": {
"webkit-svn": {
"repositories": ["WebKit", "macOS"],
"properties": {"os": "<macOS>", "wk": "<WebKit>"}
}
}
```
With this, removed the support for specifying a repository to use in generic dictionary of properties via
a dictionary with a single key of "root", "rootOptions", and "rootsExcluding". We now validate that the list of
repositories in each repository group matches exactly the ones used in buildbot properties as well as ones in
build requests.
After this patch, sync-with-buildbot.js will no longer schedule a build request without a repository group.
Run the appropriate database queries to set the repository group on each build request. Because of this change,
this patch also makes BuildbotTriggerable.prototype.syncOnce more robust against invalid build requests.
Instead of throwing an exception and exiting early, it simply skips all build requests that belong to the same
test group if the next build request to be scheduled does not specify a repository group.
* init-database.sql: Add request_repository_group column to build_requests table, and a unique constraint for
repository and group pair in triggerable_repositories table.
* public/api/update-triggerable.php:
(main): Validate and insert repository groups.
(validate_configurations): Extracted from main.
(validate_repository_groups): Added.
* public/v3/models/repository.js:
(Repository.findTopLevelByName): Added.
* public/include/build-requests-fetcher.php:
(BuildRequestsFetcher::results_internal): Include the repository group of each request in the JSON response.
* public/include/repository-group-finder.php: Added. A helper class to find the repository group for a given
triggerable for a list of repositories.
(RepositoryGroupFinder): Added.
(RepositoryGroupFinder::__construct): Added.
(RepositoryGroupFinder::find_by_repositories): Added.
(RepositoryGroupFinder::populate_map): Added.
* public/privileged-api/create-test-group.php:
(main): Each element in an array returned by ensure_commit_sets and commit_sets_from_revision_sets now contains
"set", the list of commit IDs, and "repository_group", the repository group identified for each commit set.
Use that to set the repository group in each new build request.
(commit_sets_from_revision_sets): Use RepositoryGroupFinder to find the right repository group.
(ensure_commit_sets): Ditto. There is no need to find a repository group for each commit set here since its
argument is keyed by the repository name. e.g. {"WebKit": [123, 456], "macOS": ["16A323", "16A323"]}
* public/v3/models/build-request.js:
(BuildRequest):
(BuildRequest.prototype.triggerable): Added.
(BuildRequest.prototype.repositoryGroup): Added.
(BuildRequest.constructBuildRequestsFromData): Resolve the triggerable and the repository group.
* public/v3/models/triggerable.js:
(Triggerable.prototype.name): Added.
(Triggerable.prototype.acceptedRepositories): Deleted.
(TriggerableRepositoryGroup):
(TriggerableRepositoryGroup.prototype.accepts): Added. Retruns true if the repository group
* server-tests/api-build-requests-tests.js: Added a test for getting the repository group of a build request.
* server-tests/api-manifest-tests.js: Added assertions for the repository groups.
* server-tests/api-report-tests.js:
(.emptyReport):
(.reportWithTwoLevelsOfAggregations):
* server-tests/api-update-triggerable.js: Added test cases for updating the repository groups associated with
a triggerable.
(.updateWithOSXRepositoryGroup):
(.mapRepositoriesByGroup):
* server-tests/privileged-api-create-test-group-tests.js:
(addTriggerableAndCreateTask): Add two repository groups for testing. Added assertions for repository groups
in existing test cases, and added a test case for creating a test group with two different repository groups.
* server-tests/resources/mock-data.js:
(MockData.resetV3Models): Reset TriggerableRepositoryGroup's static maps.
(MockData.emptyTriggeragbleId): Added.
(MockData.macosRepositoryId): Added.
(MockData.webkitRepositoryId): Added.
(MockData.gitWebkitRepositoryId): Added.
(MockData.addMockData): Create repository groups as needed. Renamed the "OS X" repository to "macOS" since some
tests were using the latter, and now we need mock data to be consistent across tests due to stricter checks.
(MockData.addEmptyTriggerable): Added. Used in api-update-triggerable.js.
(MockData.addMockTestGroupWithGitWebKit): Added. Used in api-build-requests-tests.js.
(MockData.addAnotherMockTestGroup): Cleanup.
(MockData.mockTestSyncConfigWithSingleBuilder): Updated the mock configuration per code changes.
(MockData.mockTestSyncConfigWithTwoBuilders): Ditto.
* server-tests/tools-buildbot-triggerable-tests.js: Updated a test case testing /api/update-triggerable to test
updating the set of repository groups in addition to the set of test, platform pairs.
(.refetchManifest): Added.
* tools/js/buildbot-syncer.js:
(BuildbotSyncer): Now takes a set of configurations shared across syncers: repositoryGroups, slaveArgument,
and buildRequestArgument as the third argument.
(BuildbotSyncer.prototype.repositoryGroups): Added.
(BuildbotSyncer.prototype._testGroupMapForBuildRequests): Cleaned up the code to use Array.prototype.find.
Also added an assertion that the build request is associated with a repository group.
(BuildbotSyncer.prototype._propertiesForBuildRequest): Removed the support for using an arbitary property to
specify a revision in favor of explicity listing each property and repository name in a repository group.
(BuildbotSyncer._loadConfig): Removed the support for "shared", which specified the set of buildbot properties
shared across syncers, the name of properties which specifies the build slave name and build request ID. These
values are not stored as top-level properties and superseded by the concept of repository groups.
(BuildbotSyncer._parseRepositoryGroup): Parses and validates repository groups.
(BuildbotSyncer._createTestConfiguration): We no longer expect each configuration to specify a dictionary of
properties or buildRequestArgument (often inherited from shared).
(BuildbotSyncer._validateAndMergeConfig): Removed "slaveArgument" and "buildRequestArgument" from the list of
allowed proeprties in each configuration now that they're specified as top-level properties.
* tools/js/buildbot-triggerable.js:
(BuildbotTriggerable.prototype.updateTriggerable): Update the associated repository groups.
(BuildbotTriggerable.prototype.syncOnce): Skip test groups for which the next build request to be scheduled is
not included in the list of valid build requests.
(BuildbotTriggerable.prototype._validateRequests): Now returns the list of valid build requests, which excludes
those that lack a repository group set.
(BuildbotTriggerable.prototype._nextRequestInGroup): Extracted from _scheduleRequestIfSlaveIsAvailable. Finds
the next build request to be scheduled for the test group.
(BuildbotTriggerable.prototype._scheduleRequestIfSlaveIsAvailable): Renamed from
_scheduleNextRequestInGroupIfSlaveIsAvailable. Now takes the syncer and the slave name as arguments instead of
a test group information since syncOnce now calls _nextRequestInGroup to find the next build request.
* tools/js/v3-models.js:
* unit-tests/build-request-tests.js: Fixed the test name.
* unit-tests/buildbot-syncer-tests.js: Removed tests for "rootOptions" and "rootsExcluding", and added tests
for parsing repository groups.
(sampleiOSConfig): Updated the mock configuration per code changes.
(sampleiOSConfigWithExpansions): Ditto.
(smallConfiguration): Ditto. Now returns the entire configuration instead of a single builder configuration.
Various test cases have been updated to reflect this.
(createSampleBuildRequest): Removed the git hash of WebKit to match the repository groups listed in the mock
configurations. The git hash was there to test "rootOptions", which this patch removed.
(samplePendingBuild): Removed "root_dict" from the list of properties. This was used to test "rootsExcluding"
which, again, this patch removed.
(sampleInProgressBuild): Ditto.
(sampleFinishedBuild): Ditto.
* unit-tests/resources/mock-v3-models.js:
(MockModels.inject): Added ock repository groups so that existing tests will continue to function.
Canonical link: https://commits.webkit.org/187490@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@215061 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-06 21:56:59 +00:00
|
|
|
let macos = Repository.findById(9);
|
|
|
|
assert(macos);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(macos.name(), 'macOS');
|
2016-03-25 21:55:34 +00:00
|
|
|
|
|
|
|
let ios = Repository.findById(22);
|
|
|
|
assert(ios);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(ios.name(), 'iOS');
|
2016-03-25 21:55:34 +00:00
|
|
|
|
|
|
|
let tracker = BugTracker.findById(1);
|
|
|
|
assert(tracker);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(tracker.name(), 'Bugzilla');
|
|
|
|
assert.strictEqual(tracker.bugUrl(123), 'https://webkit.org/b/123');
|
|
|
|
assert.strictEqual(tracker.newBugUrl(), 'https://bugs.webkit.org/');
|
|
|
|
assert.deepStrictEqual(tracker.repositories(), [webkit]);
|
2016-03-25 21:55:34 +00:00
|
|
|
|
|
|
|
tracker = BugTracker.findById(2);
|
|
|
|
assert(tracker);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(tracker.name(), 'Radar');
|
|
|
|
assert.deepStrictEqual(Repository.sortByName(tracker.repositories()), [ios, macos]);
|
2017-03-15 03:19:02 +00:00
|
|
|
});
|
2016-03-25 21:55:34 +00:00
|
|
|
});
|
|
|
|
|
2017-04-14 23:03:19 +00:00
|
|
|
it("should generate manifest with repositories and each repository should know its owned repositories", () => {
|
|
|
|
const db = TestServer.database();
|
|
|
|
return Promise.all([
|
|
|
|
db.insert('repositories', {id: 11, name: 'WebKit', url: 'https://trac.webkit.org/$1'}),
|
|
|
|
db.insert('repositories', {id: 9, name: 'OS X'}),
|
|
|
|
db.insert('repositories', {id: 22, name: 'iOS'}),
|
|
|
|
db.insert('repositories', {id: 35, name: 'JavaScriptCore', owner: 9}),
|
|
|
|
]).then(() => {
|
|
|
|
return TestServer.remoteAPI().getJSON('/api/manifest');
|
|
|
|
}).then((content) => {
|
|
|
|
let manifest = Manifest._didFetchManifest(content);
|
|
|
|
|
|
|
|
let webkit = Repository.findById(11);
|
|
|
|
assert(webkit);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(webkit.name(), 'WebKit');
|
|
|
|
assert.strictEqual(webkit.urlForRevision(123), 'https://trac.webkit.org/123');
|
|
|
|
assert.ok(!webkit.ownedRepositories());
|
2017-04-14 23:03:19 +00:00
|
|
|
|
|
|
|
let osx = Repository.findById(9);
|
|
|
|
assert(osx);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(osx.name(), 'OS X');
|
|
|
|
assert.deepStrictEqual(osx.ownedRepositories(), [Repository.findById(35)]);
|
2017-04-14 23:03:19 +00:00
|
|
|
|
|
|
|
let ios = Repository.findById(22);
|
|
|
|
assert(ios);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(ios.name(), 'iOS');
|
|
|
|
assert.ok(!ios.ownedRepositories());
|
2017-04-14 23:03:19 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2017-03-15 03:19:02 +00:00
|
|
|
it("should generate manifest with builders", () => {
|
2016-03-25 21:55:34 +00:00
|
|
|
let db = TestServer.database();
|
2017-03-15 03:19:02 +00:00
|
|
|
return Promise.all([
|
2016-03-25 21:55:34 +00:00
|
|
|
db.insert('builders', {id: 1, name: 'SomeBuilder', password_hash: 'a',
|
2019-10-24 22:00:37 +00:00
|
|
|
build_url: 'https://build.webkit.org/builders/$builderName/build/$buildTag'}),
|
2016-03-25 21:55:34 +00:00
|
|
|
db.insert('builders', {id: 2, name: 'SomeOtherBuilder', password_hash: 'b'})
|
2017-03-15 03:19:02 +00:00
|
|
|
]).then(() => {
|
2016-03-30 03:16:29 +00:00
|
|
|
return TestServer.remoteAPI().getJSON('/api/manifest');
|
2017-03-15 03:19:02 +00:00
|
|
|
}).then((content) => {
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(content.builders, {
|
2019-10-24 22:00:37 +00:00
|
|
|
'1': {name: 'SomeBuilder', buildUrl: 'https://build.webkit.org/builders/$builderName/build/$buildTag'},
|
2016-03-25 21:55:34 +00:00
|
|
|
'2': {name: 'SomeOtherBuilder', buildUrl: null}
|
|
|
|
});
|
|
|
|
|
|
|
|
let manifest = Manifest._didFetchManifest(content);
|
|
|
|
|
|
|
|
let builder = Builder.findById(1);
|
|
|
|
assert(builder);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(builder.name(), 'SomeBuilder');
|
|
|
|
assert.strictEqual(builder.urlForBuild(123), 'https://build.webkit.org/builders/SomeBuilder/build/123');
|
2016-03-25 21:55:34 +00:00
|
|
|
|
|
|
|
builder = Builder.findById(2);
|
|
|
|
assert(builder);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(builder.name(), 'SomeOtherBuilder');
|
|
|
|
assert.strictEqual(builder.urlForBuild(123), null);
|
2017-03-15 03:19:02 +00:00
|
|
|
});
|
2016-03-25 21:55:34 +00:00
|
|
|
});
|
|
|
|
|
2017-03-15 03:19:02 +00:00
|
|
|
it("should generate manifest with tests, metrics, and platforms", () => {
|
2016-03-25 21:55:34 +00:00
|
|
|
let db = TestServer.database();
|
2017-03-15 03:19:02 +00:00
|
|
|
return Promise.all([
|
2016-03-25 21:55:34 +00:00
|
|
|
db.insert('tests', {id: 1, name: 'SomeTest'}),
|
|
|
|
db.insert('tests', {id: 2, name: 'SomeOtherTest'}),
|
|
|
|
db.insert('tests', {id: 3, name: 'ChildTest', parent: 1}),
|
|
|
|
db.insert('tests', {id: 4, name: 'GrandChild', parent: 3}),
|
|
|
|
db.insert('aggregators', {id: 200, name: 'Total'}),
|
|
|
|
db.insert('test_metrics', {id: 5, test: 1, name: 'Time'}),
|
|
|
|
db.insert('test_metrics', {id: 6, test: 2, name: 'Time', aggregator: 200}),
|
|
|
|
db.insert('test_metrics', {id: 7, test: 2, name: 'Malloc', aggregator: 200}),
|
|
|
|
db.insert('test_metrics', {id: 8, test: 3, name: 'Time'}),
|
|
|
|
db.insert('test_metrics', {id: 9, test: 4, name: 'Time'}),
|
2020-10-28 01:00:35 +00:00
|
|
|
db.insert('platform_groups', {id: 1, name: 'ios'}),
|
|
|
|
db.insert('platform_groups', {id: 2, name: 'mac'}),
|
|
|
|
db.insert('platforms', {id: 23, name: 'iOS 9 iPhone 5s', group: 1}),
|
|
|
|
db.insert('platforms', {id: 46, name: 'Trunk Mavericks', group: 2}),
|
2016-03-25 21:55:34 +00:00
|
|
|
db.insert('test_configurations', {id: 101, metric: 5, platform: 46, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 102, metric: 6, platform: 46, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 103, metric: 7, platform: 46, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 104, metric: 8, platform: 46, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 105, metric: 9, platform: 46, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 106, metric: 5, platform: 23, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 107, metric: 5, platform: 23, type: 'baseline'}),
|
2017-03-15 03:19:02 +00:00
|
|
|
]).then(() => {
|
2016-03-30 03:16:29 +00:00
|
|
|
return TestServer.remoteAPI().getJSON('/api/manifest');
|
2017-03-15 03:19:02 +00:00
|
|
|
}).then((content) => {
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(content.tests, {
|
2016-03-25 21:55:34 +00:00
|
|
|
"1": {"name": "SomeTest", "parentId": null, "url": null},
|
|
|
|
"2": {"name": "SomeOtherTest", "parentId": null, "url": null},
|
|
|
|
"3": {"name": "ChildTest", "parentId": "1", "url": null},
|
|
|
|
"4": {"name": "GrandChild", "parentId": "3", "url": null},
|
|
|
|
});
|
|
|
|
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(content.metrics, {
|
2016-03-25 21:55:34 +00:00
|
|
|
'5': {name: 'Time', test: '1', aggregator: null},
|
|
|
|
'6': {name: 'Time', test: '2', aggregator: 'Total'},
|
|
|
|
'7': {name: 'Malloc', test: '2', aggregator: 'Total'},
|
|
|
|
'8': {name: 'Time', test: '3', aggregator: null},
|
|
|
|
'9': {name: 'Time', test: '4', aggregator: null},
|
|
|
|
});
|
|
|
|
|
|
|
|
let manifest = Manifest._didFetchManifest(content);
|
|
|
|
|
2020-10-28 01:00:35 +00:00
|
|
|
const someTest = Test.findById(1);
|
|
|
|
const someTestMetric = Metric.findById(5);
|
|
|
|
const someOtherTest = Test.findById(2);
|
|
|
|
const someOtherTestTime = Metric.findById(6);
|
|
|
|
const someOtherTestMalloc = Metric.findById(7);
|
|
|
|
const childTest = Test.findById(3);
|
|
|
|
const childTestMetric = Metric.findById(8);
|
|
|
|
const grandChildTest = Test.findById(4);
|
|
|
|
const ios9iphone5s = Platform.findById(23);
|
|
|
|
const mavericks = Platform.findById(46);
|
|
|
|
const iosGroup = PlatformGroup.findById(1);
|
|
|
|
const macGroup = PlatformGroup.findById(2);
|
2016-03-25 21:55:34 +00:00
|
|
|
assert(someTest);
|
|
|
|
assert(someTestMetric);
|
|
|
|
assert(someOtherTest);
|
|
|
|
assert(someOtherTestTime);
|
|
|
|
assert(someOtherTestMalloc);
|
|
|
|
assert(childTest);
|
|
|
|
assert(childTestMetric);
|
|
|
|
assert(grandChildTest);
|
|
|
|
assert(ios9iphone5s);
|
|
|
|
assert(mavericks);
|
2020-10-28 01:00:35 +00:00
|
|
|
assert(iosGroup);
|
|
|
|
assert(macGroup);
|
2016-03-25 21:55:34 +00:00
|
|
|
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(mavericks.name(), 'Trunk Mavericks');
|
2016-03-25 21:55:34 +00:00
|
|
|
assert(mavericks.hasTest(someTest));
|
|
|
|
assert(mavericks.hasTest(someOtherTest));
|
|
|
|
assert(mavericks.hasTest(childTest));
|
|
|
|
assert(mavericks.hasTest(grandChildTest));
|
|
|
|
assert(mavericks.hasMetric(someTestMetric));
|
|
|
|
assert(mavericks.hasMetric(someOtherTestTime));
|
|
|
|
assert(mavericks.hasMetric(someOtherTestMalloc));
|
|
|
|
assert(mavericks.hasMetric(childTestMetric));
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(mavericks.group(), macGroup);
|
2016-03-25 21:55:34 +00:00
|
|
|
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(ios9iphone5s.name(), 'iOS 9 iPhone 5s');
|
2016-03-25 21:55:34 +00:00
|
|
|
assert(ios9iphone5s.hasTest(someTest));
|
|
|
|
assert(!ios9iphone5s.hasTest(someOtherTest));
|
|
|
|
assert(!ios9iphone5s.hasTest(childTest));
|
|
|
|
assert(!ios9iphone5s.hasTest(grandChildTest));
|
|
|
|
assert(ios9iphone5s.hasMetric(someTestMetric));
|
|
|
|
assert(!ios9iphone5s.hasMetric(someOtherTestTime));
|
|
|
|
assert(!ios9iphone5s.hasMetric(someOtherTestMalloc));
|
|
|
|
assert(!ios9iphone5s.hasMetric(childTestMetric));
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(ios9iphone5s.group(), iosGroup);
|
2020-10-28 01:00:35 +00:00
|
|
|
|
|
|
|
const macPlatforms = macGroup.platforms();
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(macPlatforms.length, 1);
|
|
|
|
assert.strictEqual(macPlatforms[0], mavericks);
|
2020-10-28 01:00:35 +00:00
|
|
|
|
|
|
|
const iosPlatforms = iosGroup.platforms();
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(iosPlatforms.length, 1);
|
|
|
|
assert.strictEqual(iosPlatforms[0], ios9iphone5s);
|
2016-03-25 21:55:34 +00:00
|
|
|
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(someTest.name(), 'SomeTest');
|
|
|
|
assert.ok(!someTest.parentTest());
|
|
|
|
assert.deepStrictEqual(someTest.path(), [someTest]);
|
2016-03-25 21:55:34 +00:00
|
|
|
assert(!someTest.onlyContainsSingleMetric());
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(someTest.childTests(), [childTest]);
|
|
|
|
assert.deepStrictEqual(someTest.metrics(), [someTestMetric]);
|
|
|
|
|
|
|
|
assert.strictEqual(someTestMetric.name(), 'Time');
|
|
|
|
assert.strictEqual(someTestMetric.aggregatorName(), null);
|
|
|
|
assert.strictEqual(someTestMetric.label(), 'Time');
|
|
|
|
assert.deepStrictEqual(someTestMetric.childMetrics(), childTest.metrics());
|
|
|
|
assert.strictEqual(someTestMetric.fullName(), 'SomeTest : Time');
|
|
|
|
|
|
|
|
assert.strictEqual(someOtherTest.name(), 'SomeOtherTest');
|
|
|
|
assert.ok(!someOtherTest.parentTest());
|
|
|
|
assert.deepStrictEqual(someOtherTest.path(), [someOtherTest]);
|
2016-03-25 21:55:34 +00:00
|
|
|
assert(!someOtherTest.onlyContainsSingleMetric());
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(someOtherTest.childTests(), []);
|
|
|
|
assert.strictEqual(someOtherTest.metrics().length, 2);
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[0].name(), 'Time');
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[0].aggregatorName(), 'Total');
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[0].label(), 'Time : Total');
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[0].childMetrics().length, 0);
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[0].fullName(), 'SomeOtherTest : Time : Total');
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[1].name(), 'Malloc');
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[1].aggregatorName(), 'Total');
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[1].label(), 'Malloc : Total');
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[1].childMetrics().length, 0);
|
|
|
|
assert.strictEqual(someOtherTest.metrics()[1].fullName(), 'SomeOtherTest : Malloc : Total');
|
|
|
|
|
|
|
|
assert.strictEqual(childTest.name(), 'ChildTest');
|
|
|
|
assert.strictEqual(childTest.parentTest(), someTest);
|
|
|
|
assert.deepStrictEqual(childTest.path(), [someTest, childTest]);
|
2016-03-25 21:55:34 +00:00
|
|
|
assert(!childTest.onlyContainsSingleMetric());
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(childTest.childTests(), [grandChildTest]);
|
|
|
|
assert.strictEqual(childTest.metrics().length, 1);
|
|
|
|
assert.strictEqual(childTest.metrics()[0].label(), 'Time');
|
|
|
|
assert.strictEqual(childTest.metrics()[0].fullName(), 'SomeTest \u220B ChildTest : Time');
|
|
|
|
|
|
|
|
assert.strictEqual(grandChildTest.name(), 'GrandChild');
|
|
|
|
assert.strictEqual(grandChildTest.parentTest(), childTest);
|
|
|
|
assert.deepStrictEqual(grandChildTest.path(), [someTest, childTest, grandChildTest]);
|
2016-03-25 21:55:34 +00:00
|
|
|
assert(grandChildTest.onlyContainsSingleMetric());
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(grandChildTest.childTests(), []);
|
|
|
|
assert.strictEqual(grandChildTest.metrics().length, 1);
|
|
|
|
assert.strictEqual(grandChildTest.metrics()[0].label(), 'Time');
|
|
|
|
assert.strictEqual(grandChildTest.metrics()[0].fullName(), 'SomeTest \u220B ChildTest \u220B GrandChild : Time');
|
2017-03-15 03:19:02 +00:00
|
|
|
});
|
2016-03-25 21:55:34 +00:00
|
|
|
});
|
|
|
|
|
2017-03-15 03:19:02 +00:00
|
|
|
it("should generate manifest with triggerables", () => {
|
2017-01-12 07:18:28 +00:00
|
|
|
let db = TestServer.database();
|
2017-03-15 03:19:02 +00:00
|
|
|
return Promise.all([
|
2017-01-12 07:18:28 +00:00
|
|
|
db.insert('repositories', {id: 11, name: 'WebKit', url: 'https://trac.webkit.org/$1'}),
|
Each build request should be associated with a repository group
https://bugs.webkit.org/show_bug.cgi?id=170528
Rubber-stamped by Chris Dumez.
Make the buildbot syncing script use the concept of repository groups so that each repository group can post
a different set of properties to buildbot. In order to do this, we associate each build request with
a repository group to use. Each triggerable's repository groups is now updated by the syncing scripts via
/api/update-triggerable just the same way the set of the supported platform, test pairs are updated.
Each repository group specifies the list of repositories, a dictionary that maps the buildbot property name
to either a string value or a repository name enclosed in < and >:
```js
"repositoryGroups": {
"webkit-svn": {
"repositories": ["WebKit", "macOS"],
"properties": {"os": "<macOS>", "wk": "<WebKit>"}
}
}
```
With this, removed the support for specifying a repository to use in generic dictionary of properties via
a dictionary with a single key of "root", "rootOptions", and "rootsExcluding". We now validate that the list of
repositories in each repository group matches exactly the ones used in buildbot properties as well as ones in
build requests.
After this patch, sync-with-buildbot.js will no longer schedule a build request without a repository group.
Run the appropriate database queries to set the repository group on each build request. Because of this change,
this patch also makes BuildbotTriggerable.prototype.syncOnce more robust against invalid build requests.
Instead of throwing an exception and exiting early, it simply skips all build requests that belong to the same
test group if the next build request to be scheduled does not specify a repository group.
* init-database.sql: Add request_repository_group column to build_requests table, and a unique constraint for
repository and group pair in triggerable_repositories table.
* public/api/update-triggerable.php:
(main): Validate and insert repository groups.
(validate_configurations): Extracted from main.
(validate_repository_groups): Added.
* public/v3/models/repository.js:
(Repository.findTopLevelByName): Added.
* public/include/build-requests-fetcher.php:
(BuildRequestsFetcher::results_internal): Include the repository group of each request in the JSON response.
* public/include/repository-group-finder.php: Added. A helper class to find the repository group for a given
triggerable for a list of repositories.
(RepositoryGroupFinder): Added.
(RepositoryGroupFinder::__construct): Added.
(RepositoryGroupFinder::find_by_repositories): Added.
(RepositoryGroupFinder::populate_map): Added.
* public/privileged-api/create-test-group.php:
(main): Each element in an array returned by ensure_commit_sets and commit_sets_from_revision_sets now contains
"set", the list of commit IDs, and "repository_group", the repository group identified for each commit set.
Use that to set the repository group in each new build request.
(commit_sets_from_revision_sets): Use RepositoryGroupFinder to find the right repository group.
(ensure_commit_sets): Ditto. There is no need to find a repository group for each commit set here since its
argument is keyed by the repository name. e.g. {"WebKit": [123, 456], "macOS": ["16A323", "16A323"]}
* public/v3/models/build-request.js:
(BuildRequest):
(BuildRequest.prototype.triggerable): Added.
(BuildRequest.prototype.repositoryGroup): Added.
(BuildRequest.constructBuildRequestsFromData): Resolve the triggerable and the repository group.
* public/v3/models/triggerable.js:
(Triggerable.prototype.name): Added.
(Triggerable.prototype.acceptedRepositories): Deleted.
(TriggerableRepositoryGroup):
(TriggerableRepositoryGroup.prototype.accepts): Added. Retruns true if the repository group
* server-tests/api-build-requests-tests.js: Added a test for getting the repository group of a build request.
* server-tests/api-manifest-tests.js: Added assertions for the repository groups.
* server-tests/api-report-tests.js:
(.emptyReport):
(.reportWithTwoLevelsOfAggregations):
* server-tests/api-update-triggerable.js: Added test cases for updating the repository groups associated with
a triggerable.
(.updateWithOSXRepositoryGroup):
(.mapRepositoriesByGroup):
* server-tests/privileged-api-create-test-group-tests.js:
(addTriggerableAndCreateTask): Add two repository groups for testing. Added assertions for repository groups
in existing test cases, and added a test case for creating a test group with two different repository groups.
* server-tests/resources/mock-data.js:
(MockData.resetV3Models): Reset TriggerableRepositoryGroup's static maps.
(MockData.emptyTriggeragbleId): Added.
(MockData.macosRepositoryId): Added.
(MockData.webkitRepositoryId): Added.
(MockData.gitWebkitRepositoryId): Added.
(MockData.addMockData): Create repository groups as needed. Renamed the "OS X" repository to "macOS" since some
tests were using the latter, and now we need mock data to be consistent across tests due to stricter checks.
(MockData.addEmptyTriggerable): Added. Used in api-update-triggerable.js.
(MockData.addMockTestGroupWithGitWebKit): Added. Used in api-build-requests-tests.js.
(MockData.addAnotherMockTestGroup): Cleanup.
(MockData.mockTestSyncConfigWithSingleBuilder): Updated the mock configuration per code changes.
(MockData.mockTestSyncConfigWithTwoBuilders): Ditto.
* server-tests/tools-buildbot-triggerable-tests.js: Updated a test case testing /api/update-triggerable to test
updating the set of repository groups in addition to the set of test, platform pairs.
(.refetchManifest): Added.
* tools/js/buildbot-syncer.js:
(BuildbotSyncer): Now takes a set of configurations shared across syncers: repositoryGroups, slaveArgument,
and buildRequestArgument as the third argument.
(BuildbotSyncer.prototype.repositoryGroups): Added.
(BuildbotSyncer.prototype._testGroupMapForBuildRequests): Cleaned up the code to use Array.prototype.find.
Also added an assertion that the build request is associated with a repository group.
(BuildbotSyncer.prototype._propertiesForBuildRequest): Removed the support for using an arbitary property to
specify a revision in favor of explicity listing each property and repository name in a repository group.
(BuildbotSyncer._loadConfig): Removed the support for "shared", which specified the set of buildbot properties
shared across syncers, the name of properties which specifies the build slave name and build request ID. These
values are not stored as top-level properties and superseded by the concept of repository groups.
(BuildbotSyncer._parseRepositoryGroup): Parses and validates repository groups.
(BuildbotSyncer._createTestConfiguration): We no longer expect each configuration to specify a dictionary of
properties or buildRequestArgument (often inherited from shared).
(BuildbotSyncer._validateAndMergeConfig): Removed "slaveArgument" and "buildRequestArgument" from the list of
allowed proeprties in each configuration now that they're specified as top-level properties.
* tools/js/buildbot-triggerable.js:
(BuildbotTriggerable.prototype.updateTriggerable): Update the associated repository groups.
(BuildbotTriggerable.prototype.syncOnce): Skip test groups for which the next build request to be scheduled is
not included in the list of valid build requests.
(BuildbotTriggerable.prototype._validateRequests): Now returns the list of valid build requests, which excludes
those that lack a repository group set.
(BuildbotTriggerable.prototype._nextRequestInGroup): Extracted from _scheduleRequestIfSlaveIsAvailable. Finds
the next build request to be scheduled for the test group.
(BuildbotTriggerable.prototype._scheduleRequestIfSlaveIsAvailable): Renamed from
_scheduleNextRequestInGroupIfSlaveIsAvailable. Now takes the syncer and the slave name as arguments instead of
a test group information since syncOnce now calls _nextRequestInGroup to find the next build request.
* tools/js/v3-models.js:
* unit-tests/build-request-tests.js: Fixed the test name.
* unit-tests/buildbot-syncer-tests.js: Removed tests for "rootOptions" and "rootsExcluding", and added tests
for parsing repository groups.
(sampleiOSConfig): Updated the mock configuration per code changes.
(sampleiOSConfigWithExpansions): Ditto.
(smallConfiguration): Ditto. Now returns the entire configuration instead of a single builder configuration.
Various test cases have been updated to reflect this.
(createSampleBuildRequest): Removed the git hash of WebKit to match the repository groups listed in the mock
configurations. The git hash was there to test "rootOptions", which this patch removed.
(samplePendingBuild): Removed "root_dict" from the list of properties. This was used to test "rootsExcluding"
which, again, this patch removed.
(sampleInProgressBuild): Ditto.
(sampleFinishedBuild): Ditto.
* unit-tests/resources/mock-v3-models.js:
(MockModels.inject): Added ock repository groups so that existing tests will continue to function.
Canonical link: https://commits.webkit.org/187490@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@215061 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-06 21:56:59 +00:00
|
|
|
db.insert('repositories', {id: 9, name: 'macOS'}),
|
2018-04-16 06:58:36 +00:00
|
|
|
db.insert('repositories', {id: 16, name: 'Shared'}),
|
2017-03-13 09:10:29 +00:00
|
|
|
db.insert('repositories', {id: 101, name: 'WebKit', owner: 9, url: 'https://trac.webkit.org/$1'}),
|
2017-01-12 07:18:28 +00:00
|
|
|
db.insert('build_triggerables', {id: 200, name: 'build.webkit.org'}),
|
|
|
|
db.insert('build_triggerables', {id: 201, name: 'ios-build.webkit.org'}),
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
db.insert('build_triggerables', {id: 202, name: 'mac-build.webkit.org', disabled: true}),
|
2017-01-12 07:18:28 +00:00
|
|
|
db.insert('tests', {id: 1, name: 'SomeTest'}),
|
|
|
|
db.insert('tests', {id: 2, name: 'SomeOtherTest'}),
|
|
|
|
db.insert('tests', {id: 3, name: 'ChildTest', parent: 1}),
|
|
|
|
db.insert('platforms', {id: 23, name: 'iOS 9 iPhone 5s'}),
|
|
|
|
db.insert('platforms', {id: 46, name: 'Trunk Mavericks'}),
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
db.insert('platforms', {id: 104, name: 'Trunk Sierra MacBookPro11,2'}),
|
2017-01-12 07:18:28 +00:00
|
|
|
db.insert('test_metrics', {id: 5, test: 1, name: 'Time'}),
|
|
|
|
db.insert('test_metrics', {id: 8, test: 2, name: 'FrameRate'}),
|
|
|
|
db.insert('test_metrics', {id: 9, test: 3, name: 'Time'}),
|
|
|
|
db.insert('test_configurations', {id: 101, metric: 5, platform: 46, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 102, metric: 8, platform: 46, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 103, metric: 9, platform: 46, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 104, metric: 5, platform: 23, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 105, metric: 8, platform: 23, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 106, metric: 9, platform: 23, type: 'current'}),
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
db.insert('test_configurations', {id: 107, metric: 5, platform: 104, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 108, metric: 8, platform: 104, type: 'current'}),
|
|
|
|
db.insert('test_configurations', {id: 109, metric: 9, platform: 104, type: 'current'}),
|
|
|
|
db.insert('triggerable_repository_groups', {id: 300, triggerable: 200, name: 'default'}),
|
|
|
|
db.insert('triggerable_repository_groups', {id: 301, triggerable: 201, name: 'default'}),
|
|
|
|
db.insert('triggerable_repository_groups', {id: 302, triggerable: 202, name: 'system-and-webkit'}),
|
2018-04-16 06:58:36 +00:00
|
|
|
db.insert('triggerable_repository_groups', {id: 303, triggerable: 202, name: 'system-and-roots', accepts_roots: true}),
|
|
|
|
db.insert('triggerable_repository_groups', {id: 304, triggerable: 202, name: 'webkit-and-shared', hidden: true}),
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
db.insert('triggerable_repositories', {group: 300, repository: 11}),
|
|
|
|
db.insert('triggerable_repositories', {group: 301, repository: 11}),
|
|
|
|
db.insert('triggerable_repositories', {group: 302, repository: 11}),
|
2018-04-16 06:58:36 +00:00
|
|
|
db.insert('triggerable_repositories', {group: 304, repository: 11}),
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
db.insert('triggerable_repositories', {group: 302, repository: 9}),
|
2018-04-16 06:58:36 +00:00
|
|
|
db.insert('triggerable_repositories', {group: 303, repository: 9}),
|
|
|
|
db.insert('triggerable_repositories', {group: 304, repository: 16}),
|
2017-01-12 07:18:28 +00:00
|
|
|
db.insert('triggerable_configurations', {triggerable: 200, test: 1, platform: 46}),
|
|
|
|
db.insert('triggerable_configurations', {triggerable: 200, test: 2, platform: 46}),
|
|
|
|
db.insert('triggerable_configurations', {triggerable: 201, test: 1, platform: 23}),
|
|
|
|
db.insert('triggerable_configurations', {triggerable: 201, test: 2, platform: 23}),
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
db.insert('triggerable_configurations', {triggerable: 202, test: 1, platform: 104}),
|
|
|
|
db.insert('triggerable_configurations', {triggerable: 202, test: 2, platform: 104}),
|
2017-03-15 03:19:02 +00:00
|
|
|
]).then(() => {
|
2017-01-12 07:18:28 +00:00
|
|
|
return Manifest.fetch();
|
2017-03-15 03:19:02 +00:00
|
|
|
}).then(() => {
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const webkit = Repository.findById(11);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(webkit.name(), 'WebKit');
|
|
|
|
assert.strictEqual(webkit.urlForRevision(123), 'https://trac.webkit.org/123');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const osWebkit1 = Repository.findById(101);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(osWebkit1.name(), 'WebKit');
|
|
|
|
assert.strictEqual(parseInt(osWebkit1.ownerId()), 9);
|
|
|
|
assert.strictEqual(osWebkit1.urlForRevision(123), 'https://trac.webkit.org/123');
|
2017-03-13 09:10:29 +00:00
|
|
|
|
Each build request should be associated with a repository group
https://bugs.webkit.org/show_bug.cgi?id=170528
Rubber-stamped by Chris Dumez.
Make the buildbot syncing script use the concept of repository groups so that each repository group can post
a different set of properties to buildbot. In order to do this, we associate each build request with
a repository group to use. Each triggerable's repository groups is now updated by the syncing scripts via
/api/update-triggerable just the same way the set of the supported platform, test pairs are updated.
Each repository group specifies the list of repositories, a dictionary that maps the buildbot property name
to either a string value or a repository name enclosed in < and >:
```js
"repositoryGroups": {
"webkit-svn": {
"repositories": ["WebKit", "macOS"],
"properties": {"os": "<macOS>", "wk": "<WebKit>"}
}
}
```
With this, removed the support for specifying a repository to use in generic dictionary of properties via
a dictionary with a single key of "root", "rootOptions", and "rootsExcluding". We now validate that the list of
repositories in each repository group matches exactly the ones used in buildbot properties as well as ones in
build requests.
After this patch, sync-with-buildbot.js will no longer schedule a build request without a repository group.
Run the appropriate database queries to set the repository group on each build request. Because of this change,
this patch also makes BuildbotTriggerable.prototype.syncOnce more robust against invalid build requests.
Instead of throwing an exception and exiting early, it simply skips all build requests that belong to the same
test group if the next build request to be scheduled does not specify a repository group.
* init-database.sql: Add request_repository_group column to build_requests table, and a unique constraint for
repository and group pair in triggerable_repositories table.
* public/api/update-triggerable.php:
(main): Validate and insert repository groups.
(validate_configurations): Extracted from main.
(validate_repository_groups): Added.
* public/v3/models/repository.js:
(Repository.findTopLevelByName): Added.
* public/include/build-requests-fetcher.php:
(BuildRequestsFetcher::results_internal): Include the repository group of each request in the JSON response.
* public/include/repository-group-finder.php: Added. A helper class to find the repository group for a given
triggerable for a list of repositories.
(RepositoryGroupFinder): Added.
(RepositoryGroupFinder::__construct): Added.
(RepositoryGroupFinder::find_by_repositories): Added.
(RepositoryGroupFinder::populate_map): Added.
* public/privileged-api/create-test-group.php:
(main): Each element in an array returned by ensure_commit_sets and commit_sets_from_revision_sets now contains
"set", the list of commit IDs, and "repository_group", the repository group identified for each commit set.
Use that to set the repository group in each new build request.
(commit_sets_from_revision_sets): Use RepositoryGroupFinder to find the right repository group.
(ensure_commit_sets): Ditto. There is no need to find a repository group for each commit set here since its
argument is keyed by the repository name. e.g. {"WebKit": [123, 456], "macOS": ["16A323", "16A323"]}
* public/v3/models/build-request.js:
(BuildRequest):
(BuildRequest.prototype.triggerable): Added.
(BuildRequest.prototype.repositoryGroup): Added.
(BuildRequest.constructBuildRequestsFromData): Resolve the triggerable and the repository group.
* public/v3/models/triggerable.js:
(Triggerable.prototype.name): Added.
(Triggerable.prototype.acceptedRepositories): Deleted.
(TriggerableRepositoryGroup):
(TriggerableRepositoryGroup.prototype.accepts): Added. Retruns true if the repository group
* server-tests/api-build-requests-tests.js: Added a test for getting the repository group of a build request.
* server-tests/api-manifest-tests.js: Added assertions for the repository groups.
* server-tests/api-report-tests.js:
(.emptyReport):
(.reportWithTwoLevelsOfAggregations):
* server-tests/api-update-triggerable.js: Added test cases for updating the repository groups associated with
a triggerable.
(.updateWithOSXRepositoryGroup):
(.mapRepositoriesByGroup):
* server-tests/privileged-api-create-test-group-tests.js:
(addTriggerableAndCreateTask): Add two repository groups for testing. Added assertions for repository groups
in existing test cases, and added a test case for creating a test group with two different repository groups.
* server-tests/resources/mock-data.js:
(MockData.resetV3Models): Reset TriggerableRepositoryGroup's static maps.
(MockData.emptyTriggeragbleId): Added.
(MockData.macosRepositoryId): Added.
(MockData.webkitRepositoryId): Added.
(MockData.gitWebkitRepositoryId): Added.
(MockData.addMockData): Create repository groups as needed. Renamed the "OS X" repository to "macOS" since some
tests were using the latter, and now we need mock data to be consistent across tests due to stricter checks.
(MockData.addEmptyTriggerable): Added. Used in api-update-triggerable.js.
(MockData.addMockTestGroupWithGitWebKit): Added. Used in api-build-requests-tests.js.
(MockData.addAnotherMockTestGroup): Cleanup.
(MockData.mockTestSyncConfigWithSingleBuilder): Updated the mock configuration per code changes.
(MockData.mockTestSyncConfigWithTwoBuilders): Ditto.
* server-tests/tools-buildbot-triggerable-tests.js: Updated a test case testing /api/update-triggerable to test
updating the set of repository groups in addition to the set of test, platform pairs.
(.refetchManifest): Added.
* tools/js/buildbot-syncer.js:
(BuildbotSyncer): Now takes a set of configurations shared across syncers: repositoryGroups, slaveArgument,
and buildRequestArgument as the third argument.
(BuildbotSyncer.prototype.repositoryGroups): Added.
(BuildbotSyncer.prototype._testGroupMapForBuildRequests): Cleaned up the code to use Array.prototype.find.
Also added an assertion that the build request is associated with a repository group.
(BuildbotSyncer.prototype._propertiesForBuildRequest): Removed the support for using an arbitary property to
specify a revision in favor of explicity listing each property and repository name in a repository group.
(BuildbotSyncer._loadConfig): Removed the support for "shared", which specified the set of buildbot properties
shared across syncers, the name of properties which specifies the build slave name and build request ID. These
values are not stored as top-level properties and superseded by the concept of repository groups.
(BuildbotSyncer._parseRepositoryGroup): Parses and validates repository groups.
(BuildbotSyncer._createTestConfiguration): We no longer expect each configuration to specify a dictionary of
properties or buildRequestArgument (often inherited from shared).
(BuildbotSyncer._validateAndMergeConfig): Removed "slaveArgument" and "buildRequestArgument" from the list of
allowed proeprties in each configuration now that they're specified as top-level properties.
* tools/js/buildbot-triggerable.js:
(BuildbotTriggerable.prototype.updateTriggerable): Update the associated repository groups.
(BuildbotTriggerable.prototype.syncOnce): Skip test groups for which the next build request to be scheduled is
not included in the list of valid build requests.
(BuildbotTriggerable.prototype._validateRequests): Now returns the list of valid build requests, which excludes
those that lack a repository group set.
(BuildbotTriggerable.prototype._nextRequestInGroup): Extracted from _scheduleRequestIfSlaveIsAvailable. Finds
the next build request to be scheduled for the test group.
(BuildbotTriggerable.prototype._scheduleRequestIfSlaveIsAvailable): Renamed from
_scheduleNextRequestInGroupIfSlaveIsAvailable. Now takes the syncer and the slave name as arguments instead of
a test group information since syncOnce now calls _nextRequestInGroup to find the next build request.
* tools/js/v3-models.js:
* unit-tests/build-request-tests.js: Fixed the test name.
* unit-tests/buildbot-syncer-tests.js: Removed tests for "rootOptions" and "rootsExcluding", and added tests
for parsing repository groups.
(sampleiOSConfig): Updated the mock configuration per code changes.
(sampleiOSConfigWithExpansions): Ditto.
(smallConfiguration): Ditto. Now returns the entire configuration instead of a single builder configuration.
Various test cases have been updated to reflect this.
(createSampleBuildRequest): Removed the git hash of WebKit to match the repository groups listed in the mock
configurations. The git hash was there to test "rootOptions", which this patch removed.
(samplePendingBuild): Removed "root_dict" from the list of properties. This was used to test "rootsExcluding"
which, again, this patch removed.
(sampleInProgressBuild): Ditto.
(sampleFinishedBuild): Ditto.
* unit-tests/resources/mock-v3-models.js:
(MockModels.inject): Added ock repository groups so that existing tests will continue to function.
Canonical link: https://commits.webkit.org/187490@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@215061 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-06 21:56:59 +00:00
|
|
|
const macos = Repository.findById(9);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(macos.name(), 'macOS');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
2018-04-16 06:58:36 +00:00
|
|
|
const shared = Repository.findById(16);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(shared.name(), 'Shared');
|
2018-04-16 06:58:36 +00:00
|
|
|
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const someTest = Test.findById(1);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(someTest.name(), 'SomeTest');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const someOtherTest = Test.findById(2);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(someOtherTest.name(), 'SomeOtherTest');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const childTest = Test.findById(3);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(childTest.name(), 'ChildTest');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const ios9iphone5s = Platform.findById(23);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(ios9iphone5s.name(), 'iOS 9 iPhone 5s');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const mavericks = Platform.findById(46);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(mavericks.name(), 'Trunk Mavericks');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const sierra = Platform.findById(104);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(sierra.name(), 'Trunk Sierra MacBookPro11,2');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(Triggerable.all().length, 3);
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
|
Each build request should be associated with a repository group
https://bugs.webkit.org/show_bug.cgi?id=170528
Rubber-stamped by Chris Dumez.
Make the buildbot syncing script use the concept of repository groups so that each repository group can post
a different set of properties to buildbot. In order to do this, we associate each build request with
a repository group to use. Each triggerable's repository groups is now updated by the syncing scripts via
/api/update-triggerable just the same way the set of the supported platform, test pairs are updated.
Each repository group specifies the list of repositories, a dictionary that maps the buildbot property name
to either a string value or a repository name enclosed in < and >:
```js
"repositoryGroups": {
"webkit-svn": {
"repositories": ["WebKit", "macOS"],
"properties": {"os": "<macOS>", "wk": "<WebKit>"}
}
}
```
With this, removed the support for specifying a repository to use in generic dictionary of properties via
a dictionary with a single key of "root", "rootOptions", and "rootsExcluding". We now validate that the list of
repositories in each repository group matches exactly the ones used in buildbot properties as well as ones in
build requests.
After this patch, sync-with-buildbot.js will no longer schedule a build request without a repository group.
Run the appropriate database queries to set the repository group on each build request. Because of this change,
this patch also makes BuildbotTriggerable.prototype.syncOnce more robust against invalid build requests.
Instead of throwing an exception and exiting early, it simply skips all build requests that belong to the same
test group if the next build request to be scheduled does not specify a repository group.
* init-database.sql: Add request_repository_group column to build_requests table, and a unique constraint for
repository and group pair in triggerable_repositories table.
* public/api/update-triggerable.php:
(main): Validate and insert repository groups.
(validate_configurations): Extracted from main.
(validate_repository_groups): Added.
* public/v3/models/repository.js:
(Repository.findTopLevelByName): Added.
* public/include/build-requests-fetcher.php:
(BuildRequestsFetcher::results_internal): Include the repository group of each request in the JSON response.
* public/include/repository-group-finder.php: Added. A helper class to find the repository group for a given
triggerable for a list of repositories.
(RepositoryGroupFinder): Added.
(RepositoryGroupFinder::__construct): Added.
(RepositoryGroupFinder::find_by_repositories): Added.
(RepositoryGroupFinder::populate_map): Added.
* public/privileged-api/create-test-group.php:
(main): Each element in an array returned by ensure_commit_sets and commit_sets_from_revision_sets now contains
"set", the list of commit IDs, and "repository_group", the repository group identified for each commit set.
Use that to set the repository group in each new build request.
(commit_sets_from_revision_sets): Use RepositoryGroupFinder to find the right repository group.
(ensure_commit_sets): Ditto. There is no need to find a repository group for each commit set here since its
argument is keyed by the repository name. e.g. {"WebKit": [123, 456], "macOS": ["16A323", "16A323"]}
* public/v3/models/build-request.js:
(BuildRequest):
(BuildRequest.prototype.triggerable): Added.
(BuildRequest.prototype.repositoryGroup): Added.
(BuildRequest.constructBuildRequestsFromData): Resolve the triggerable and the repository group.
* public/v3/models/triggerable.js:
(Triggerable.prototype.name): Added.
(Triggerable.prototype.acceptedRepositories): Deleted.
(TriggerableRepositoryGroup):
(TriggerableRepositoryGroup.prototype.accepts): Added. Retruns true if the repository group
* server-tests/api-build-requests-tests.js: Added a test for getting the repository group of a build request.
* server-tests/api-manifest-tests.js: Added assertions for the repository groups.
* server-tests/api-report-tests.js:
(.emptyReport):
(.reportWithTwoLevelsOfAggregations):
* server-tests/api-update-triggerable.js: Added test cases for updating the repository groups associated with
a triggerable.
(.updateWithOSXRepositoryGroup):
(.mapRepositoriesByGroup):
* server-tests/privileged-api-create-test-group-tests.js:
(addTriggerableAndCreateTask): Add two repository groups for testing. Added assertions for repository groups
in existing test cases, and added a test case for creating a test group with two different repository groups.
* server-tests/resources/mock-data.js:
(MockData.resetV3Models): Reset TriggerableRepositoryGroup's static maps.
(MockData.emptyTriggeragbleId): Added.
(MockData.macosRepositoryId): Added.
(MockData.webkitRepositoryId): Added.
(MockData.gitWebkitRepositoryId): Added.
(MockData.addMockData): Create repository groups as needed. Renamed the "OS X" repository to "macOS" since some
tests were using the latter, and now we need mock data to be consistent across tests due to stricter checks.
(MockData.addEmptyTriggerable): Added. Used in api-update-triggerable.js.
(MockData.addMockTestGroupWithGitWebKit): Added. Used in api-build-requests-tests.js.
(MockData.addAnotherMockTestGroup): Cleanup.
(MockData.mockTestSyncConfigWithSingleBuilder): Updated the mock configuration per code changes.
(MockData.mockTestSyncConfigWithTwoBuilders): Ditto.
* server-tests/tools-buildbot-triggerable-tests.js: Updated a test case testing /api/update-triggerable to test
updating the set of repository groups in addition to the set of test, platform pairs.
(.refetchManifest): Added.
* tools/js/buildbot-syncer.js:
(BuildbotSyncer): Now takes a set of configurations shared across syncers: repositoryGroups, slaveArgument,
and buildRequestArgument as the third argument.
(BuildbotSyncer.prototype.repositoryGroups): Added.
(BuildbotSyncer.prototype._testGroupMapForBuildRequests): Cleaned up the code to use Array.prototype.find.
Also added an assertion that the build request is associated with a repository group.
(BuildbotSyncer.prototype._propertiesForBuildRequest): Removed the support for using an arbitary property to
specify a revision in favor of explicity listing each property and repository name in a repository group.
(BuildbotSyncer._loadConfig): Removed the support for "shared", which specified the set of buildbot properties
shared across syncers, the name of properties which specifies the build slave name and build request ID. These
values are not stored as top-level properties and superseded by the concept of repository groups.
(BuildbotSyncer._parseRepositoryGroup): Parses and validates repository groups.
(BuildbotSyncer._createTestConfiguration): We no longer expect each configuration to specify a dictionary of
properties or buildRequestArgument (often inherited from shared).
(BuildbotSyncer._validateAndMergeConfig): Removed "slaveArgument" and "buildRequestArgument" from the list of
allowed proeprties in each configuration now that they're specified as top-level properties.
* tools/js/buildbot-triggerable.js:
(BuildbotTriggerable.prototype.updateTriggerable): Update the associated repository groups.
(BuildbotTriggerable.prototype.syncOnce): Skip test groups for which the next build request to be scheduled is
not included in the list of valid build requests.
(BuildbotTriggerable.prototype._validateRequests): Now returns the list of valid build requests, which excludes
those that lack a repository group set.
(BuildbotTriggerable.prototype._nextRequestInGroup): Extracted from _scheduleRequestIfSlaveIsAvailable. Finds
the next build request to be scheduled for the test group.
(BuildbotTriggerable.prototype._scheduleRequestIfSlaveIsAvailable): Renamed from
_scheduleNextRequestInGroupIfSlaveIsAvailable. Now takes the syncer and the slave name as arguments instead of
a test group information since syncOnce now calls _nextRequestInGroup to find the next build request.
* tools/js/v3-models.js:
* unit-tests/build-request-tests.js: Fixed the test name.
* unit-tests/buildbot-syncer-tests.js: Removed tests for "rootOptions" and "rootsExcluding", and added tests
for parsing repository groups.
(sampleiOSConfig): Updated the mock configuration per code changes.
(sampleiOSConfigWithExpansions): Ditto.
(smallConfiguration): Ditto. Now returns the entire configuration instead of a single builder configuration.
Various test cases have been updated to reflect this.
(createSampleBuildRequest): Removed the git hash of WebKit to match the repository groups listed in the mock
configurations. The git hash was there to test "rootOptions", which this patch removed.
(samplePendingBuild): Removed "root_dict" from the list of properties. This was used to test "rootsExcluding"
which, again, this patch removed.
(sampleInProgressBuild): Ditto.
(sampleFinishedBuild): Ditto.
* unit-tests/resources/mock-v3-models.js:
(MockModels.inject): Added ock repository groups so that existing tests will continue to function.
Canonical link: https://commits.webkit.org/187490@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@215061 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-06 21:56:59 +00:00
|
|
|
const macosTriggerable = Triggerable.findByTestConfiguration(someTest, mavericks);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(macosTriggerable.name(), 'build.webkit.org');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(Triggerable.findByTestConfiguration(someOtherTest, mavericks), macosTriggerable);
|
|
|
|
assert.strictEqual(Triggerable.findByTestConfiguration(childTest, mavericks), macosTriggerable);
|
2017-01-12 07:18:28 +00:00
|
|
|
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
const iosTriggerable = Triggerable.findByTestConfiguration(someOtherTest, ios9iphone5s);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.notStrictEqual(iosTriggerable, macosTriggerable);
|
|
|
|
assert.strictEqual(iosTriggerable.name(), 'ios-build.webkit.org');
|
2017-01-12 07:18:28 +00:00
|
|
|
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(Triggerable.findByTestConfiguration(someOtherTest, ios9iphone5s), iosTriggerable);
|
|
|
|
assert.strictEqual(Triggerable.findByTestConfiguration(childTest, ios9iphone5s), iosTriggerable);
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
|
|
|
|
const macTriggerable = Triggerable.findByTestConfiguration(someTest, sierra);
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(macTriggerable.name(), 'mac-build.webkit.org');
|
2018-01-18 06:06:50 +00:00
|
|
|
assert(macTriggerable.acceptedTests().has(someTest));
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
|
|
|
|
const groups = macTriggerable.repositoryGroups();
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.deepStrictEqual(groups.length, 3);
|
Introduce the notion of repository groups to triggerables
https://bugs.webkit.org/show_bug.cgi?id=170228
Reviewed by Chris Dumez.
On some triggerable, it's desirable to specify multiple sets of repositories that are accepted.
For example, if a repository X transitioned from Subversion to Git, and if a triggerable accepted X and
some other repository Y, then it's desirable to two sets: (X-Subversion, Y) and (X-Git, Y) since neither
(X-Subversion, X-Git) nor (X-Subversion, X-Git, Y) makes sense as a set.
This patch introduces triggerable_repository_groups table to represent a set of repositories accepted by
a triggerable. It has many to one relationship to build_triggerables and triggerable_repositories in turn
now has many to one relationship to triggerable_repository_groups instead of build_triggerables.
Also make it possible to disable a triggerable e.g. a set of tests and platforms are no longer supported.
We don't want to delete the triggerable completely from the database since it would result in the associated
A/B testing results being purged, which is not desirale.
To migrate an existing database, run the following transaction:
```sql
BEGIN;
ALTER TABLE build_triggerables ADD COLUMN triggerable_disabled boolean NOT NULL DEFAULT FALSE;
CREATE TABLE triggerable_repository_groups (
repositorygroup_id serial PRIMARY KEY,
repositorygroup_triggerable integer REFERENCES build_triggerables NOT NULL,
repositorygroup_name varchar(256) NOT NULL,
repositorygroup_description varchar(256),
repositorygroup_accepts_roots boolean NOT NULL DEFAULT FALSE,
CONSTRAINT repository_group_name_must_be_unique_for_triggerable
UNIQUE(repositorygroup_triggerable, repositorygroup_name));
INSERT INTO triggerable_repository_groups (repositorygroup_triggerable, repositorygroup_name)
SELECT triggerable_id, 'default' FROM build_triggerables;
ALTER TABLE triggerable_repositories ADD COLUMN trigrepo_group integer REFERENCES triggerable_repository_groups;
UPDATE triggerable_repositories SET trigrepo_group = repositorygroup_id FROM triggerable_repository_groups
WHERE trigrepo_triggerable = repositorygroup_triggerable;
ALTER TABLE triggerable_repositories ALTER COLUMN trigrepo_group SET NOT NULL;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_triggerable;
ALTER TABLE triggerable_repositories DROP COLUMN trigrepo_sub_roots;
END;
```
* init-database.sql:
* public/admin/triggerables.php: Use a custom column to make forms to add and configure repository groups.
(insert_triggerable_repositories): Added.
(generate_repository_list): Added.
(generate_repository_form): Added.
(generate_repository_checkboxes): Now generates checkboxes for a repository group instead of a triggerable.
* public/include/manifest-generator.php:
(fetch_triggerables): Fixed the bug that we were not filtering results with query in /api/triggerable.
Rewrote it to include an array of repository groups, which in turn contains an array of repositories along
with its name and a description, and a boolean indicating whether it accepts a custom root file or not.
The boolean will be used when we're adding the support for perf try bots. We will keep acceptedRepositories
since it's still used by detect-changes.js.
* public/v3/models/manifest.js:
(Manifest._didFetchManifest): Resolve repositoriy, test, and platform IDs to their respective objects.
* public/v3/models/triggerable.js:
(Triggerable):
(Triggerable.prototype.isDisabled): Added.
(Triggerable.prototype.repositoryGroups): Added.
(Triggerable.prototype.acceptsTest): Added.
(TriggerableRepositoryGroup): Added.
(TriggerableRepositoryGroup.prototype.description): Added.
(TriggerableRepositoryGroup.prototype.acceptsCustomRoots): Added.
(TriggerableRepositoryGroup.prototype.repositories): Added.
* public/v3/pages/analysis-task-page.js:
(AnalysisTaskPage.prototype._didFetchTask): Don't use a disabled triggerable.
* server-tests/api-manifest-tests.js: Updated a test case to test repository groups.
* tools/js/database.js:
(tableToPrefixMap): Added triggerable_repository_groups.
* tools/js/v3-models.js: Imported TriggerableRepositoryGroup from triggerable.js.
Canonical link: https://commits.webkit.org/187454@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@214975 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-05 23:12:46 +00:00
|
|
|
TriggerableRepositoryGroup.sortByName(groups);
|
|
|
|
|
Each build request should be associated with a repository group
https://bugs.webkit.org/show_bug.cgi?id=170528
Rubber-stamped by Chris Dumez.
Make the buildbot syncing script use the concept of repository groups so that each repository group can post
a different set of properties to buildbot. In order to do this, we associate each build request with
a repository group to use. Each triggerable's repository groups is now updated by the syncing scripts via
/api/update-triggerable just the same way the set of the supported platform, test pairs are updated.
Each repository group specifies the list of repositories, a dictionary that maps the buildbot property name
to either a string value or a repository name enclosed in < and >:
```js
"repositoryGroups": {
"webkit-svn": {
"repositories": ["WebKit", "macOS"],
"properties": {"os": "<macOS>", "wk": "<WebKit>"}
}
}
```
With this, removed the support for specifying a repository to use in generic dictionary of properties via
a dictionary with a single key of "root", "rootOptions", and "rootsExcluding". We now validate that the list of
repositories in each repository group matches exactly the ones used in buildbot properties as well as ones in
build requests.
After this patch, sync-with-buildbot.js will no longer schedule a build request without a repository group.
Run the appropriate database queries to set the repository group on each build request. Because of this change,
this patch also makes BuildbotTriggerable.prototype.syncOnce more robust against invalid build requests.
Instead of throwing an exception and exiting early, it simply skips all build requests that belong to the same
test group if the next build request to be scheduled does not specify a repository group.
* init-database.sql: Add request_repository_group column to build_requests table, and a unique constraint for
repository and group pair in triggerable_repositories table.
* public/api/update-triggerable.php:
(main): Validate and insert repository groups.
(validate_configurations): Extracted from main.
(validate_repository_groups): Added.
* public/v3/models/repository.js:
(Repository.findTopLevelByName): Added.
* public/include/build-requests-fetcher.php:
(BuildRequestsFetcher::results_internal): Include the repository group of each request in the JSON response.
* public/include/repository-group-finder.php: Added. A helper class to find the repository group for a given
triggerable for a list of repositories.
(RepositoryGroupFinder): Added.
(RepositoryGroupFinder::__construct): Added.
(RepositoryGroupFinder::find_by_repositories): Added.
(RepositoryGroupFinder::populate_map): Added.
* public/privileged-api/create-test-group.php:
(main): Each element in an array returned by ensure_commit_sets and commit_sets_from_revision_sets now contains
"set", the list of commit IDs, and "repository_group", the repository group identified for each commit set.
Use that to set the repository group in each new build request.
(commit_sets_from_revision_sets): Use RepositoryGroupFinder to find the right repository group.
(ensure_commit_sets): Ditto. There is no need to find a repository group for each commit set here since its
argument is keyed by the repository name. e.g. {"WebKit": [123, 456], "macOS": ["16A323", "16A323"]}
* public/v3/models/build-request.js:
(BuildRequest):
(BuildRequest.prototype.triggerable): Added.
(BuildRequest.prototype.repositoryGroup): Added.
(BuildRequest.constructBuildRequestsFromData): Resolve the triggerable and the repository group.
* public/v3/models/triggerable.js:
(Triggerable.prototype.name): Added.
(Triggerable.prototype.acceptedRepositories): Deleted.
(TriggerableRepositoryGroup):
(TriggerableRepositoryGroup.prototype.accepts): Added. Retruns true if the repository group
* server-tests/api-build-requests-tests.js: Added a test for getting the repository group of a build request.
* server-tests/api-manifest-tests.js: Added assertions for the repository groups.
* server-tests/api-report-tests.js:
(.emptyReport):
(.reportWithTwoLevelsOfAggregations):
* server-tests/api-update-triggerable.js: Added test cases for updating the repository groups associated with
a triggerable.
(.updateWithOSXRepositoryGroup):
(.mapRepositoriesByGroup):
* server-tests/privileged-api-create-test-group-tests.js:
(addTriggerableAndCreateTask): Add two repository groups for testing. Added assertions for repository groups
in existing test cases, and added a test case for creating a test group with two different repository groups.
* server-tests/resources/mock-data.js:
(MockData.resetV3Models): Reset TriggerableRepositoryGroup's static maps.
(MockData.emptyTriggeragbleId): Added.
(MockData.macosRepositoryId): Added.
(MockData.webkitRepositoryId): Added.
(MockData.gitWebkitRepositoryId): Added.
(MockData.addMockData): Create repository groups as needed. Renamed the "OS X" repository to "macOS" since some
tests were using the latter, and now we need mock data to be consistent across tests due to stricter checks.
(MockData.addEmptyTriggerable): Added. Used in api-update-triggerable.js.
(MockData.addMockTestGroupWithGitWebKit): Added. Used in api-build-requests-tests.js.
(MockData.addAnotherMockTestGroup): Cleanup.
(MockData.mockTestSyncConfigWithSingleBuilder): Updated the mock configuration per code changes.
(MockData.mockTestSyncConfigWithTwoBuilders): Ditto.
* server-tests/tools-buildbot-triggerable-tests.js: Updated a test case testing /api/update-triggerable to test
updating the set of repository groups in addition to the set of test, platform pairs.
(.refetchManifest): Added.
* tools/js/buildbot-syncer.js:
(BuildbotSyncer): Now takes a set of configurations shared across syncers: repositoryGroups, slaveArgument,
and buildRequestArgument as the third argument.
(BuildbotSyncer.prototype.repositoryGroups): Added.
(BuildbotSyncer.prototype._testGroupMapForBuildRequests): Cleaned up the code to use Array.prototype.find.
Also added an assertion that the build request is associated with a repository group.
(BuildbotSyncer.prototype._propertiesForBuildRequest): Removed the support for using an arbitary property to
specify a revision in favor of explicity listing each property and repository name in a repository group.
(BuildbotSyncer._loadConfig): Removed the support for "shared", which specified the set of buildbot properties
shared across syncers, the name of properties which specifies the build slave name and build request ID. These
values are not stored as top-level properties and superseded by the concept of repository groups.
(BuildbotSyncer._parseRepositoryGroup): Parses and validates repository groups.
(BuildbotSyncer._createTestConfiguration): We no longer expect each configuration to specify a dictionary of
properties or buildRequestArgument (often inherited from shared).
(BuildbotSyncer._validateAndMergeConfig): Removed "slaveArgument" and "buildRequestArgument" from the list of
allowed proeprties in each configuration now that they're specified as top-level properties.
* tools/js/buildbot-triggerable.js:
(BuildbotTriggerable.prototype.updateTriggerable): Update the associated repository groups.
(BuildbotTriggerable.prototype.syncOnce): Skip test groups for which the next build request to be scheduled is
not included in the list of valid build requests.
(BuildbotTriggerable.prototype._validateRequests): Now returns the list of valid build requests, which excludes
those that lack a repository group set.
(BuildbotTriggerable.prototype._nextRequestInGroup): Extracted from _scheduleRequestIfSlaveIsAvailable. Finds
the next build request to be scheduled for the test group.
(BuildbotTriggerable.prototype._scheduleRequestIfSlaveIsAvailable): Renamed from
_scheduleNextRequestInGroupIfSlaveIsAvailable. Now takes the syncer and the slave name as arguments instead of
a test group information since syncOnce now calls _nextRequestInGroup to find the next build request.
* tools/js/v3-models.js:
* unit-tests/build-request-tests.js: Fixed the test name.
* unit-tests/buildbot-syncer-tests.js: Removed tests for "rootOptions" and "rootsExcluding", and added tests
for parsing repository groups.
(sampleiOSConfig): Updated the mock configuration per code changes.
(sampleiOSConfigWithExpansions): Ditto.
(smallConfiguration): Ditto. Now returns the entire configuration instead of a single builder configuration.
Various test cases have been updated to reflect this.
(createSampleBuildRequest): Removed the git hash of WebKit to match the repository groups listed in the mock
configurations. The git hash was there to test "rootOptions", which this patch removed.
(samplePendingBuild): Removed "root_dict" from the list of properties. This was used to test "rootsExcluding"
which, again, this patch removed.
(sampleInProgressBuild): Ditto.
(sampleFinishedBuild): Ditto.
* unit-tests/resources/mock-v3-models.js:
(MockModels.inject): Added ock repository groups so that existing tests will continue to function.
Canonical link: https://commits.webkit.org/187490@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@215061 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-04-06 21:56:59 +00:00
|
|
|
const emptyCustomSet = new CustomCommitSet;
|
|
|
|
|
|
|
|
const customSetWithOSX = new CustomCommitSet;
|
|
|
|
customSetWithOSX.setRevisionForRepository(macos, '10.11 15A284');
|
|
|
|
|
|
|
|
const cusomSetWithOSXAndWebKit = new CustomCommitSet;
|
|
|
|
cusomSetWithOSXAndWebKit.setRevisionForRepository(webkit, '191622');
|
|
|
|
cusomSetWithOSXAndWebKit.setRevisionForRepository(macos, '10.11 15A284');
|
|
|
|
|
|
|
|
const cusomSetWithWebKit = new CustomCommitSet;
|
|
|
|
cusomSetWithWebKit.setRevisionForRepository(webkit, '191622');
|
|
|
|
|
2018-04-16 06:58:36 +00:00
|
|
|
const cusomSetWithWebKitAndShared = new CustomCommitSet;
|
|
|
|
cusomSetWithWebKitAndShared.setRevisionForRepository(webkit, '191622');
|
|
|
|
cusomSetWithWebKitAndShared.setRevisionForRepository(shared, '86456');
|
|
|
|
|
2021-03-06 14:31:56 +00:00
|
|
|
assert.strictEqual(groups[0].name(), 'system-and-roots');
|
|
|
|
assert.strictEqual(groups[0].isHidden(), false);
|
|
|
|
assert.strictEqual(groups[0].acceptsCustomRoots(), true);
|
|
|
|
assert.deepStrictEqual(Repository.sortByName(groups[0].repositories()), [macos]);
|
|
|
|
assert.strictEqual(groups[0].accepts(emptyCustomSet), false);
|
|
|
|
assert.strictEqual(groups[0].accepts(customSetWithOSX), true);
|
|
|
|
assert.strictEqual(groups[0].accepts(cusomSetWithOSXAndWebKit), false);
|
|
|
|
assert.strictEqual(groups[0].accepts(cusomSetWithWebKitAndShared), false);
|
|
|
|
assert.strictEqual(groups[0].accepts(cusomSetWithWebKit), false);
|
|
|
|
|
|
|
|
assert.strictEqual(groups[1].name(), 'system-and-webkit');
|
|
|
|
assert.strictEqual(groups[1].isHidden(), false);
|
|
|
|
assert.strictEqual(groups[1].acceptsCustomRoots(), false);
|
|
|
|
assert.deepStrictEqual(Repository.sortByName(groups[1].repositories()), [webkit, macos]);
|
|
|
|
assert.strictEqual(groups[1].accepts(emptyCustomSet), false);
|
|
|
|
assert.strictEqual(groups[1].accepts(customSetWithOSX), false);
|
|
|
|
assert.strictEqual(groups[1].accepts(cusomSetWithOSXAndWebKit), true);
|
|
|
|
assert.strictEqual(groups[1].accepts(cusomSetWithWebKitAndShared), false);
|
|
|
|
assert.strictEqual(groups[1].accepts(cusomSetWithWebKit), false);
|
|
|
|
|
|
|
|
assert.strictEqual(groups[2].name(), 'webkit-and-shared');
|
|
|
|
assert.strictEqual(groups[2].isHidden(), true);
|
|
|
|
assert.strictEqual(groups[2].acceptsCustomRoots(), false);
|
|
|
|
assert.deepStrictEqual(Repository.sortByName(groups[2].repositories()), [shared, webkit]);
|
|
|
|
assert.strictEqual(groups[2].accepts(emptyCustomSet), false);
|
|
|
|
assert.strictEqual(groups[2].accepts(customSetWithOSX), false);
|
|
|
|
assert.strictEqual(groups[2].accepts(cusomSetWithOSXAndWebKit), false);
|
|
|
|
assert.strictEqual(groups[2].accepts(cusomSetWithWebKitAndShared), true);
|
|
|
|
assert.strictEqual(groups[2].accepts(cusomSetWithWebKit), false);
|
2017-03-15 03:19:02 +00:00
|
|
|
});
|
2017-01-12 07:18:28 +00:00
|
|
|
});
|
|
|
|
|
2016-03-25 21:55:34 +00:00
|
|
|
});
|