ahuston-0/hydra
1
0
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases Wiki Activity
hydra/src/lib/Hydra/Schema/Projects.pm

283 lines
4.1 KiB
Perl
Raw Normal View History

Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
use utf8;
* More global substitution.
2008-11-25 11:01:42 +00:00
package Hydra::Schema::Projects;
* Basic job info in the database.
2008-11-04 18:23:28 +00:00
2009-10-23 15:05:16 +00:00
# Created by DBIx::Class::Schema::Loader
# DO NOT MODIFY THE FIRST PART OF THIS FILE
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=head1 NAME
Hydra::Schema::Projects
=cut
* Basic job info in the database.
2008-11-04 18:23:28 +00:00
use strict;
use warnings;
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
use base 'DBIx::Class::Core';
Merge in the first bits of the API work The catalyst-action-rest branch from shlevy/hydra was an exploration of using Catalyst::Action::REST to create a JSON API for hydra. This commit merges in the best bits from that experiment, with the goal that further API endpoints can be added incrementally. In addition to migrating more endpoints, there is potential for improvement in what's already been done: * The web interface can be updated to use the same non-GET endpoints as the JSON interface (using x-tunneled-method) instead of having a separate endpoint * The web rendering should use the $c->stash->{resource} data structure where applicable rather than putting the same data in two places in the stash * Which columns to render for each endpoint is a completely debatable question * Hydra::Component::ToJSON should turn has_many relations that have strings as their primary keys into objects instead of arrays Fixes NixOS/hydra#98 Signed-off-by: Shea Levy <shea@shealevy.com>
2013-06-17 12:34:21 -04:00
=head1 COMPONENTS LOADED
=over 4
=item * L<Hydra::Component::ToJSON>
=back
=cut
__PACKAGE__->load_components("+Hydra::Component::ToJSON");
sql: Generate models from postgresql Lowercasing is due to postgresql not having case-sensitive table names. It always technically workde before, but those table names never existed literally. The switch to generating from postgresql is to handle an upcoming addition of an auto-incrementign ID to the Jobset table. Sqlite doesn't seem to be able to handle the table having an auto incrementing ID field which isn't the primary key, but we can't change the primary key trivially. Since hydra doesn't support sqlite and hasn't for many year anyway, it is easier to just generate from pgsql directly.
2020-02-06 12:23:47 -05:00
=head1 TABLE: C<projects>
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=cut
* Basic job info in the database.
2008-11-04 18:23:28 +00:00
sql: Generate models from postgresql Lowercasing is due to postgresql not having case-sensitive table names. It always technically workde before, but those table names never existed literally. The switch to generating from postgresql is to handle an upcoming addition of an auto-incrementign ID to the Jobset table. Sqlite doesn't seem to be able to handle the table having an auto incrementing ID field which isn't the primary key, but we can't change the primary key trivially. Since hydra doesn't support sqlite and hasn't for many year anyway, it is easier to just generate from pgsql directly.
2020-02-06 12:23:47 -05:00
__PACKAGE__->table("projects");
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=head1 ACCESSORS
=head2 name
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
data_type: 'text'
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
is_nullable: 0
=head2 displayname
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
data_type: 'text'
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
is_nullable: 0
=head2 description
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
data_type: 'text'
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
is_nullable: 1
=head2 enabled
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
data_type: 'integer'
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
default_value: 1
is_nullable: 0
added hide feature for project/jobset
2010-06-04 14:43:28 +00:00
=head2 hidden
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
data_type: 'integer'
added hide feature for project/jobset
2010-06-04 14:43:28 +00:00
default_value: 0
is_nullable: 0
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=head2 owner
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
data_type: 'text'
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
is_foreign_key: 1
is_nullable: 0
=head2 homepage
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
data_type: 'text'
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
is_nullable: 1
Enable declarative projects. This allows fully declarative project specifications. This is best illustrated by example: * I create a new project, setting the declarative spec file to "spec.json" and the declarative input to a git repo pointing at git://github.com/shlevy/declarative-hydra-example.git * hydra creates a special ".jobsets" jobset alongside the project * Just before evaluating the ".jobsets" jobset, hydra fetches declarative-hydra-example.git, reads spec.json as a jobset spec, and updates the jobset's configuration accordingly: { "enabled": 1, "hidden": false, "description": "Jobsets", "nixexprinput": "src", "nixexprpath": "default.nix", "checkinterval": 300, "schedulingshares": 100, "enableemail": false, "emailoverride": "", "keepnr": 3, "inputs": { "src": { "type": "git", "value": "git://github.com/shlevy/declarative-hydra-example.git", "emailresponsible": false }, "nixpkgs": { "type": "git", "value": "git://github.com/NixOS/nixpkgs.git release-16.03", "emailresponsible": false } } } * When the "jobsets" job of the ".jobsets" jobset completes, hydra reads its output as a JSON representation of a dictionary of jobset specs and creates a jobset named "master" configured accordingly (In this example, this is the same configuration as .jobsets itself, except using release.nix instead of default.nix): { "enabled": 1, "hidden": false, "description": "js", "nixexprinput": "src", "nixexprpath": "release.nix", "checkinterval": 300, "schedulingshares": 100, "enableemail": false, "emailoverride": "", "keepnr": 3, "inputs": { "src": { "type": "git", "value": "git://github.com/shlevy/declarative-hydra-example.git", "emailresponsible": false }, "nixpkgs": { "type": "git", "value": "git://github.com/NixOS/nixpkgs.git release-16.03", "emailresponsible": false } } }
2016-03-11 18:14:58 -05:00
=head2 declfile
data_type: 'text'
is_nullable: 1
=head2 decltype
data_type: 'text'
is_nullable: 1
=head2 declvalue
data_type: 'text'
is_nullable: 1
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=cut
* Basic job info in the database.
2008-11-04 18:23:28 +00:00
__PACKAGE__->add_columns(
"name",
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
{ data_type => "text", is_nullable => 0 },
2008-11-12 23:45:11 +00:00
"displayname",
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
{ data_type => "text", is_nullable => 0 },
2008-11-12 23:45:11 +00:00
"description",
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
{ data_type => "text", is_nullable => 1 },
2008-11-17 23:59:20 +00:00
"enabled",
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
{ data_type => "integer", default_value => 1, is_nullable => 0 },
added hide feature for project/jobset
2010-06-04 14:43:28 +00:00
"hidden",
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
{ data_type => "integer", default_value => 0, is_nullable => 0 },
* Role-based access control. Only admins can create projects. Only admins or project owners can edit or delete a project.
2008-11-26 23:25:24 +00:00
"owner",
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
{ data_type => "text", is_foreign_key => 1, is_nullable => 0 },
* Add a link to each project's homepage. Suggested by karltk.
2009-02-11 23:14:28 +00:00
"homepage",
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
{ data_type => "text", is_nullable => 1 },
Enable declarative projects. This allows fully declarative project specifications. This is best illustrated by example: * I create a new project, setting the declarative spec file to "spec.json" and the declarative input to a git repo pointing at git://github.com/shlevy/declarative-hydra-example.git * hydra creates a special ".jobsets" jobset alongside the project * Just before evaluating the ".jobsets" jobset, hydra fetches declarative-hydra-example.git, reads spec.json as a jobset spec, and updates the jobset's configuration accordingly: { "enabled": 1, "hidden": false, "description": "Jobsets", "nixexprinput": "src", "nixexprpath": "default.nix", "checkinterval": 300, "schedulingshares": 100, "enableemail": false, "emailoverride": "", "keepnr": 3, "inputs": { "src": { "type": "git", "value": "git://github.com/shlevy/declarative-hydra-example.git", "emailresponsible": false }, "nixpkgs": { "type": "git", "value": "git://github.com/NixOS/nixpkgs.git release-16.03", "emailresponsible": false } } } * When the "jobsets" job of the ".jobsets" jobset completes, hydra reads its output as a JSON representation of a dictionary of jobset specs and creates a jobset named "master" configured accordingly (In this example, this is the same configuration as .jobsets itself, except using release.nix instead of default.nix): { "enabled": 1, "hidden": false, "description": "js", "nixexprinput": "src", "nixexprpath": "release.nix", "checkinterval": 300, "schedulingshares": 100, "enableemail": false, "emailoverride": "", "keepnr": 3, "inputs": { "src": { "type": "git", "value": "git://github.com/shlevy/declarative-hydra-example.git", "emailresponsible": false }, "nixpkgs": { "type": "git", "value": "git://github.com/NixOS/nixpkgs.git release-16.03", "emailresponsible": false } } }
2016-03-11 18:14:58 -05:00
"declfile",
{ data_type => "text", is_nullable => 1 },
"decltype",
{ data_type => "text", is_nullable => 1 },
"declvalue",
{ data_type => "text", is_nullable => 1 },
* Basic job info in the database.
2008-11-04 18:23:28 +00:00
);
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=head1 PRIMARY KEY
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=over 4
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=item * L</name>
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=back
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=cut
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
__PACKAGE__->set_primary_key("name");
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=head1 RELATIONS
Add support for tracking custom metrics Builds can now emit metrics that Hydra will store in its database and render as time series via flot charts. Typical applications are to keep track of performance indicators, coverage percentages, artifact sizes, and so on. For example, a coverage build can emit the coverage percentage as follows: echo "lineCoverage $pct %" > $out/nix-support/hydra-metrics Graphs of all metrics for a job can be seen at http://.../job/<project>/<jobset>/<job>#tabs-charts Specific metrics are also visible at http://.../job/<project>/<jobset>/<job>/metric/<metric> The latter URL also allows getting the data in JSON format (e.g. via "curl -H 'Accept: application/json'").
2015-07-31 00:57:30 +02:00
=head2 buildmetrics
Type: has_many
Related object: L<Hydra::Schema::BuildMetrics>
=cut
__PACKAGE__->has_many(
"buildmetrics",
"Hydra::Schema::BuildMetrics",
{ "foreign.project" => "self.name" },
undef,
);
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=head2 builds
added newsitems, added some admin options to clear various caches.
2010-04-27 13:29:08 +00:00
Type: has_many
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
Related object: L<Hydra::Schema::Builds>
added newsitems, added some admin options to clear various caches.
2010-04-27 13:29:08 +00:00
=cut
__PACKAGE__->has_many(
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
"builds",
"Hydra::Schema::Builds",
added newsitems, added some admin options to clear various caches.
2010-04-27 13:29:08 +00:00
{ "foreign.project" => "self.name" },
Remove the logfile and logSize columns from the database It's pointless to store these, since Nix knows where the logs are. Also handle (in fact require) Nix's new log storage scheme. Also some cleanups in the build page.
2013-01-22 22:48:02 +01:00
undef,
added newsitems, added some admin options to clear various caches.
2010-04-27 13:29:08 +00:00
);
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=head2 jobsetevals
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Type: has_many
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
Related object: L<Hydra::Schema::JobsetEvals>
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=cut
* Represent jobs explicitly in the DB.
2009-03-13 14:49:25 +00:00
__PACKAGE__->has_many(
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
"jobsetevals",
"Hydra::Schema::JobsetEvals",
* Represent jobs explicitly in the DB.
2009-03-13 14:49:25 +00:00
{ "foreign.project" => "self.name" },
Remove the logfile and logSize columns from the database It's pointless to store these, since Nix knows where the logs are. Also handle (in fact require) Nix's new log storage scheme. Also some cleanups in the build page.
2013-01-22 22:48:02 +01:00
undef,
* Represent jobs explicitly in the DB.
2009-03-13 14:49:25 +00:00
);
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
When renaming a jobset, add a redirect from the old name
2014-04-23 23:12:00 +02:00
=head2 jobsetrenames
Type: has_many
Related object: L<Hydra::Schema::JobsetRenames>
=cut
__PACKAGE__->has_many(
"jobsetrenames",
"Hydra::Schema::JobsetRenames",
{ "foreign.project" => "self.name" },
undef,
);
Partially revert 1c20cfdf2403feb78cef515faf15c04d5c9f17bd Not clear why update-dbix messed up the Jobsets and Projects classes. This will probably happen again in the future...
2014-10-01 15:28:18 +02:00
=head2 jobsets
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Type: has_many
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
Related object: L<Hydra::Schema::Jobsets>
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=cut
* Cleaned up the foreign key constraints. * Generate SQLite and PostgreSQL schemas from hydra.sql.
2009-10-21 12:25:43 +00:00
__PACKAGE__->has_many(
Partially revert 1c20cfdf2403feb78cef515faf15c04d5c9f17bd Not clear why update-dbix messed up the Jobsets and Projects classes. This will probably happen again in the future...
2014-10-01 15:28:18 +02:00
"jobsets",
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
"Hydra::Schema::Jobsets",
* Cleaned up the foreign key constraints. * Generate SQLite and PostgreSQL schemas from hydra.sql.
2009-10-21 12:25:43 +00:00
{ "foreign.project" => "self.name" },
Remove the logfile and logSize columns from the database It's pointless to store these, since Nix knows where the logs are. Also handle (in fact require) Nix's new log storage scheme. Also some cleanups in the build page.
2013-01-22 22:48:02 +01:00
undef,
* Cleaned up the foreign key constraints. * Generate SQLite and PostgreSQL schemas from hydra.sql.
2009-10-21 12:25:43 +00:00
);
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=head2 owner
Type: belongs_to
Related object: L<Hydra::Schema::Users>
=cut
Remove the logfile and logSize columns from the database It's pointless to store these, since Nix knows where the logs are. Also handle (in fact require) Nix's new log storage scheme. Also some cleanups in the build page.
2013-01-22 22:48:02 +01:00
__PACKAGE__->belongs_to(
"owner",
"Hydra::Schema::Users",
{ username => "owner" },
{ is_deferrable => 0, on_delete => "NO ACTION", on_update => "CASCADE" },
);
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
=head2 projectmembers
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Type: has_many
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
Related object: L<Hydra::Schema::ProjectMembers>
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
=cut
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
__PACKAGE__->has_many(
Keep track of the database schema version The singleton table SchemaVersion contains the current version of the Hydra database schema. This can be used to upgrade the schema on the fly. Also reran the DBIx::Class schema loader.
2011-12-05 14:29:29 +01:00
"projectmembers",
"Hydra::Schema::ProjectMembers",
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
{ "foreign.project" => "self.name" },
Remove the logfile and logSize columns from the database It's pointless to store these, since Nix knows where the logs are. Also handle (in fact require) Nix's new log storage scheme. Also some cleanups in the build page.
2013-01-22 22:48:02 +01:00
undef,
* Basic release management: releases are now dynamically computed as database queries from a set of jobs that have to be in a release. E.g. a patchelf release might consist of the jobs "tarball", "build", and "rpm_fedora10i386". Here the first job ("tarball") is the primary job: all the others have it as an input. The primary job supplies the identity of the release.
2008-11-27 15:16:06 +00:00
);
generated schema with new dbix class schema loader, grrrrrr
2010-02-25 09:50:04 +00:00
Add a dashboard Currently the dashboard allows users to get a quick overview of the status of jobs they're interested in, but more will be added, e.g. viewing all your jobsets or all jobs of which you're a maintainer.
2013-10-14 20:07:26 +02:00
=head2 starredjobs
Type: has_many
Related object: L<Hydra::Schema::StarredJobs>
=cut
__PACKAGE__->has_many(
"starredjobs",
"Hydra::Schema::StarredJobs",
{ "foreign.project" => "self.name" },
undef,
);
Remove the logfile and logSize columns from the database It's pointless to store these, since Nix knows where the logs are. Also handle (in fact require) Nix's new log storage scheme. Also some cleanups in the build page.
2013-01-22 22:48:02 +01:00
=head2 usernames
Type: many_to_many
Composing rels: L</projectmembers> -> username
=cut
__PACKAGE__->many_to_many("usernames", "projectmembers", "username");
* Basic job info in the database.
2008-11-04 18:23:28 +00:00
Normalize nixexpr{input,path} from builds to jobsetevals. Duplicating this data on every record of the builds table cost approximately 4G of duplication. Note that the database migration included took about 4h45m on an untuned server which uses very slow rotational disks in a RAID5 setup, with not a lot of RAM. I imagine in production it might take an hour or two, but not 4. If this should become a chunked migration, I can do that. Note: Because of the question about chunked migrations, I have NOT YET tested this migration thoroughly enough for merge.
2021-01-22 07:14:24 -05:00
# Created by DBIx::Class::Schema::Loader v0.07049 @ 2021-01-22 07:11:57
# DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:Ff5gJejFu+02b0lInobOoQ
Cleanup Project model Signed-off-by: Shea Levy <shea@shealevy.com>
2013-10-24 10:42:01 -04:00
my %hint = (
columns => [
"name",
"displayname",
"description",
"enabled",
"hidden",
"owner"
],
relations => {
jobsets => "name"
}
);
sub json_hint {
return \%hint;
}
* Basic job info in the database.
2008-11-04 18:23:28 +00:00
1;
Reference in New Issue Copy Permalink