Show More
@@ -0,0 +1,39 b'' | |||
|
1 | |RCE| 4.11.5 |RNS| | |
|
2 | ------------------ | |
|
3 | ||
|
4 | Release Date | |
|
5 | ^^^^^^^^^^^^ | |
|
6 | ||
|
7 | - 2018-02-21 | |
|
8 | ||
|
9 | ||
|
10 | New Features | |
|
11 | ^^^^^^^^^^^^ | |
|
12 | ||
|
13 | ||
|
14 | ||
|
15 | General | |
|
16 | ^^^^^^^ | |
|
17 | ||
|
18 | ||
|
19 | ||
|
20 | Security | |
|
21 | ^^^^^^^^ | |
|
22 | ||
|
23 | ||
|
24 | ||
|
25 | Performance | |
|
26 | ^^^^^^^^^^^ | |
|
27 | ||
|
28 | ||
|
29 | ||
|
30 | Fixes | |
|
31 | ^^^^^ | |
|
32 | ||
|
33 | - Auth: fixed a regression with external auth new users creation. | |
|
34 | ||
|
35 | ||
|
36 | Upgrade notes | |
|
37 | ^^^^^^^^^^^^^ | |
|
38 | ||
|
39 | - Unscheduled bugfix release. |
@@ -1,35 +1,36 b'' | |||
|
1 | 1 | 1bd3e92b7e2e2d2024152b34bb88dff1db544a71 v4.0.0 |
|
2 | 2 | 170c5398320ea6cddd50955e88d408794c21d43a v4.0.1 |
|
3 | 3 | c3fe200198f5aa34cf2e4066df2881a9cefe3704 v4.1.0 |
|
4 | 4 | 7fd5c850745e2ea821fb4406af5f4bff9b0a7526 v4.1.1 |
|
5 | 5 | 41c87da28a179953df86061d817bc35533c66dd2 v4.1.2 |
|
6 | 6 | baaf9f5bcea3bae0ef12ae20c8b270482e62abb6 v4.2.0 |
|
7 | 7 | 32a70c7e56844a825f61df496ee5eaf8c3c4e189 v4.2.1 |
|
8 | 8 | fa695cdb411d294679ac081d595ac654e5613b03 v4.3.0 |
|
9 | 9 | 0e4dc11b58cad833c513fe17bac39e6850edf959 v4.3.1 |
|
10 | 10 | 8a876f48f5cb1d018b837db28ff928500cb32cfb v4.4.0 |
|
11 | 11 | 8dd86b410b1aac086ffdfc524ef300f896af5047 v4.4.1 |
|
12 | 12 | d2514226abc8d3b4f6fb57765f47d1b6fb360a05 v4.4.2 |
|
13 | 13 | 27d783325930af6dad2741476c0d0b1b7c8415c2 v4.5.0 |
|
14 | 14 | 7f2016f352abcbdba4a19d4039c386e9629449da v4.5.1 |
|
15 | 15 | 416fec799314c70a5c780fb28b3357b08869333a v4.5.2 |
|
16 | 16 | 27c3b85fafc83143e6678fbc3da69e1615bcac55 v4.6.0 |
|
17 | 17 | 5ad13deb9118c2a5243d4032d4d9cc174e5872db v4.6.1 |
|
18 | 18 | 2be921e01fa24bb102696ada596f87464c3666f6 v4.7.0 |
|
19 | 19 | 7198bdec29c2872c974431d55200d0398354cdb1 v4.7.1 |
|
20 | 20 | bd1c8d230fe741c2dfd7100a0ef39fd0774fd581 v4.7.2 |
|
21 | 21 | 9731914f89765d9628dc4dddc84bc9402aa124c8 v4.8.0 |
|
22 | 22 | c5a2b7d0e4bbdebc4a62d7b624befe375207b659 v4.9.0 |
|
23 | 23 | d9aa3b27ac9f7e78359775c75fedf7bfece232f1 v4.9.1 |
|
24 | 24 | 4ba4d74981cec5d6b28b158f875a2540952c2f74 v4.10.0 |
|
25 | 25 | 0a6821cbd6b0b3c21503002f88800679fa35ab63 v4.10.1 |
|
26 | 26 | 434ad90ec8d621f4416074b84f6e9ce03964defb v4.10.2 |
|
27 | 27 | 68baee10e698da2724c6e0f698c03a6abb993bf2 v4.10.3 |
|
28 | 28 | 00821d3afd1dce3f4767cc353f84a17f7d5218a1 v4.10.4 |
|
29 | 29 | 22f6744ad8cc274311825f63f953e4dee2ea5cb9 v4.10.5 |
|
30 | 30 | 96eb24bea2f5f9258775245e3f09f6fa0a4dda01 v4.10.6 |
|
31 | 31 | 3121217a812c956d7dd5a5875821bd73e8002a32 v4.11.0 |
|
32 | 32 | fa98b454715ac5b912f39e84af54345909a2a805 v4.11.1 |
|
33 | 33 | 3982abcfdcc229a723cebe52d3a9bcff10bba08e v4.11.2 |
|
34 | 34 | 33195f145db9172f0a8f1487e09207178a6ab065 v4.11.3 |
|
35 | 35 | 194c74f33e32bbae6fc4d71ec5a999cff3c13605 v4.11.4 |
|
36 | 8fbd8b0c3ddc2fa4ac9e4ca16942a03eb593df2d v4.11.5 |
@@ -1,52 +1,52 b'' | |||
|
1 | 1 | ======================= |
|
2 | 2 | DB Schema and Migration |
|
3 | 3 | ======================= |
|
4 | 4 | |
|
5 | 5 | To create or alter tables in the database, it's necessary to change a couple of |
|
6 | 6 | files, apart from configuring the settings pointing to the latest database |
|
7 | 7 | schema. |
|
8 | 8 | |
|
9 | 9 | |
|
10 | 10 | Database Model and ORM |
|
11 | 11 | ---------------------- |
|
12 | 12 | |
|
13 | 13 | On ``rhodecode.model.db`` you will find the database definition of all tables and |
|
14 | 14 | fields. Any freshly installed database will be correctly created by the definitions |
|
15 | 15 | here. So, any change to this file will affect the tests without having to change |
|
16 | 16 | any other file. |
|
17 | 17 | |
|
18 | 18 | A second layer are the business classes inside ``rhodecode.model``. |
|
19 | 19 | |
|
20 | 20 | |
|
21 | 21 | Database Migration |
|
22 | 22 | ------------------ |
|
23 | 23 | |
|
24 | 24 | Three files play a role when creating database migrations: |
|
25 | 25 | |
|
26 | 26 | * Database schema inside ``rhodecode.lib.dbmigrate`` |
|
27 | 27 | * Database version inside ``rhodecode.lib.dbmigrate`` |
|
28 | 28 | * Configuration ``__dbversion__`` at ``rhodecode.__init__`` |
|
29 | 29 | |
|
30 | 30 | |
|
31 | 31 | Schema is a snapshot of the database version BEFORE the migration. So, it's |
|
32 | 32 | the initial state before any changes were added. The name convention is |
|
33 | 33 | the latest release version where the snapshot was created, and not the |
|
34 | 34 | target version of this code. |
|
35 | 35 | |
|
36 | 36 | Version is the method that will define how to UPGRADE/DOWNGRADE the database. |
|
37 | 37 | |
|
38 | 38 | ``rhodecode.__init__`` contains only a variable that defines up to which version of |
|
39 | 39 | the database will be used to upgrade. Eg.: ``__dbversion__ = 45`` |
|
40 | 40 | |
|
41 | 41 | |
|
42 | 42 | For examples on how to create those files, please see the existing code. |
|
43 | 43 | |
|
44 | 44 | |
|
45 | 45 | Migration Command |
|
46 | 46 | ^^^^^^^^^^^^^^^^^ |
|
47 | 47 | |
|
48 | 48 | After you've changed the database ORM and migration files, you can run:: |
|
49 | 49 | |
|
50 |
|
|
|
50 | rc-upgrade-db <ini-file> | |
|
51 | 51 | |
|
52 | 52 | The database will be upgraded up to the version defined in the ``__init__`` file. No newline at end of file |
@@ -1,226 +1,226 b'' | |||
|
1 | 1 | .. _dev-setup: |
|
2 | 2 | |
|
3 | 3 | =================== |
|
4 | 4 | Development setup |
|
5 | 5 | =================== |
|
6 | 6 | |
|
7 | 7 | |
|
8 | 8 | RhodeCode Enterprise runs inside a Nix managed environment. This ensures build |
|
9 | 9 | environment dependencies are correctly declared and installed during setup. |
|
10 | 10 | It also enables atomic upgrades, rollbacks, and multiple instances of RhodeCode |
|
11 | 11 | Enterprise running with isolation. |
|
12 | 12 | |
|
13 | 13 | To set up RhodeCode Enterprise inside the Nix environment, use the following steps: |
|
14 | 14 | |
|
15 | 15 | |
|
16 | 16 | |
|
17 | 17 | Setup Nix Package Manager |
|
18 | 18 | ------------------------- |
|
19 | 19 | |
|
20 | 20 | To install the Nix Package Manager, please run:: |
|
21 | 21 | |
|
22 | 22 | $ curl https://nixos.org/nix/install | sh |
|
23 | 23 | |
|
24 | 24 | or go to https://nixos.org/nix/ and follow the installation instructions. |
|
25 | 25 | Once this is correctly set up on your system, you should be able to use the |
|
26 | 26 | following commands: |
|
27 | 27 | |
|
28 | 28 | * `nix-env` |
|
29 | 29 | |
|
30 | 30 | * `nix-shell` |
|
31 | 31 | |
|
32 | 32 | |
|
33 | 33 | .. tip:: |
|
34 | 34 | |
|
35 | 35 | Update your channels frequently by running ``nix-channel --update``. |
|
36 | 36 | |
|
37 | 37 | .. note:: |
|
38 | 38 | |
|
39 | 39 | To uninstall nix run the following: |
|
40 | 40 | |
|
41 | 41 | remove the . "$HOME/.nix-profile/etc/profile.d/nix.sh" line in your ~/.profile or ~/.bash_profile |
|
42 | 42 | rm -rf $HOME/{.nix-channels,.nix-defexpr,.nix-profile,.config/nixpkgs} |
|
43 | 43 | sudo rm -rf /nix |
|
44 | 44 | |
|
45 | 45 | Switch nix to the latest STABLE channel |
|
46 | 46 | --------------------------------------- |
|
47 | 47 | |
|
48 | 48 | run:: |
|
49 | 49 | |
|
50 | 50 | nix-channel --add https://nixos.org/channels/nixos-16.03 nixpkgs |
|
51 | 51 | |
|
52 | 52 | Followed by:: |
|
53 | 53 | |
|
54 | 54 | nix-channel --update |
|
55 | 55 | |
|
56 | 56 | |
|
57 | 57 | Install required binaries |
|
58 | 58 | ------------------------- |
|
59 | 59 | |
|
60 | 60 | We need some handy tools first. |
|
61 | 61 | |
|
62 | 62 | run:: |
|
63 | 63 | |
|
64 | 64 | nix-env -i nix-prefetch-hg |
|
65 | 65 | nix-env -i nix-prefetch-git |
|
66 | 66 | |
|
67 | 67 | |
|
68 | 68 | Clone the required repositories |
|
69 | 69 | ------------------------------- |
|
70 | 70 | |
|
71 | 71 | After Nix is set up, clone the RhodeCode Enterprise Community Edition and |
|
72 | 72 | RhodeCode VCSServer repositories into the same directory. |
|
73 | 73 | RhodeCode currently is using Mercurial Version Control System, please make sure |
|
74 | 74 | you have it installed before continuing. |
|
75 | 75 | |
|
76 | 76 | To obtain the required sources, use the following commands:: |
|
77 | 77 | |
|
78 | 78 | mkdir rhodecode-develop && cd rhodecode-develop |
|
79 | 79 | hg clone https://code.rhodecode.com/rhodecode-enterprise-ce |
|
80 | 80 | hg clone https://code.rhodecode.com/rhodecode-vcsserver |
|
81 | 81 | |
|
82 | 82 | .. note:: |
|
83 | 83 | |
|
84 | 84 | If you cannot clone the repository, please contact us via support@rhodecode.com |
|
85 | 85 | |
|
86 | 86 | |
|
87 | 87 | Install some required libraries |
|
88 | 88 | ------------------------------- |
|
89 | 89 | |
|
90 | 90 | There are some required drivers and dev libraries that we need to install to |
|
91 | 91 | test RhodeCode under different types of databases. For example in Ubuntu we |
|
92 | 92 | need to install the following. |
|
93 | 93 | |
|
94 | 94 | required libraries:: |
|
95 | 95 | |
|
96 | 96 | sudo apt-get install libapr1-dev libaprutil1-dev |
|
97 | 97 | sudo apt-get install libsvn-dev |
|
98 | 98 | sudo apt-get install mysql-server libmysqlclient-dev |
|
99 | 99 | sudo apt-get install postgresql postgresql-contrib libpq-dev |
|
100 | 100 | sudo apt-get install libcurl4-openssl-dev |
|
101 | 101 | |
|
102 | 102 | |
|
103 | 103 | Enter the Development Shell |
|
104 | 104 | --------------------------- |
|
105 | 105 | |
|
106 | 106 | The final step is to start the development shells. To do this, run the |
|
107 | 107 | following command from inside the cloned repository:: |
|
108 | 108 | |
|
109 | 109 | #first, the vcsserver |
|
110 | 110 | cd ~/rhodecode-vcsserver |
|
111 | 111 | nix-shell |
|
112 | 112 | |
|
113 | 113 | # then enterprise sources |
|
114 | 114 | cd ~/rhodecode-enterprise-ce |
|
115 | 115 | nix-shell |
|
116 | 116 | |
|
117 | 117 | .. note:: |
|
118 | 118 | |
|
119 | 119 | On the first run, this will take a while to download and optionally compile |
|
120 | 120 | a few things. The following runs will be faster. The development shell works |
|
121 | 121 | fine on both MacOS and Linux platforms. |
|
122 | 122 | |
|
123 | 123 | |
|
124 | 124 | Create config.nix for development |
|
125 | 125 | --------------------------------- |
|
126 | 126 | |
|
127 | 127 | In order to run proper tests and setup linking across projects, a config.nix |
|
128 | 128 | file needs to be setup:: |
|
129 | 129 | |
|
130 | 130 | # create config |
|
131 | 131 | mkdir -p ~/.nixpkgs |
|
132 | 132 | touch ~/.nixpkgs/config.nix |
|
133 | 133 | |
|
134 | 134 | # put the below content into the ~/.nixpkgs/config.nix file |
|
135 | 135 | # adjusts, the path to where you cloned your repositories. |
|
136 | 136 | |
|
137 | 137 | { |
|
138 | 138 | rc = { |
|
139 | 139 | sources = { |
|
140 | 140 | rhodecode-vcsserver = "/home/dev/rhodecode-vcsserver"; |
|
141 | 141 | rhodecode-enterprise-ce = "/home/dev/rhodecode-enterprise-ce"; |
|
142 | 142 | rhodecode-enterprise-ee = "/home/dev/rhodecode-enterprise-ee"; |
|
143 | 143 | }; |
|
144 | 144 | }; |
|
145 | 145 | } |
|
146 | 146 | |
|
147 | 147 | |
|
148 | 148 | |
|
149 | 149 | Creating a Development Configuration |
|
150 | 150 | ------------------------------------ |
|
151 | 151 | |
|
152 | 152 | To create a development environment for RhodeCode Enterprise, |
|
153 | 153 | use the following steps: |
|
154 | 154 | |
|
155 | 155 | 1. Create a copy of vcsserver config: |
|
156 | 156 | `cp ~/rhodecode-vcsserver/configs/development.ini ~/rhodecode-vcsserver/configs/dev.ini` |
|
157 | 157 | 2. Create a copy of rhodocode config: |
|
158 | 158 | `cp ~/rhodecode-enterprise-ce/configs/development.ini ~/rhodecode-enterprise-ce/configs/dev.ini` |
|
159 | 159 | 3. Adjust the configuration settings to your needs if needed. |
|
160 | 160 | |
|
161 | 161 | .. note:: |
|
162 | 162 | |
|
163 | 163 | It is recommended to use the name `dev.ini` since it's included in .hgignore file. |
|
164 | 164 | |
|
165 | 165 | |
|
166 | 166 | Setup the Development Database |
|
167 | 167 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
168 | 168 | |
|
169 | 169 | To create a development database, use the following example. This is a one |
|
170 | 170 | time operation executed from the nix-shell of rhodecode-enterprise-ce sources :: |
|
171 | 171 | |
|
172 |
|
|
|
172 | rc-setup-app dev.ini \ | |
|
173 | 173 | --user=admin --password=secret \ |
|
174 | 174 | --email=admin@example.com \ |
|
175 | 175 | --repos=~/my_dev_repos |
|
176 | 176 | |
|
177 | 177 | |
|
178 | 178 | Compile CSS and JavaScript |
|
179 | 179 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
180 | 180 | |
|
181 | 181 | To use the application's frontend and prepare it for production deployment, |
|
182 | 182 | you will need to compile the CSS and JavaScript with Grunt. |
|
183 | 183 | This is easily done from within the nix-shell using the following command:: |
|
184 | 184 | |
|
185 | 185 | grunt |
|
186 | 186 | |
|
187 | 187 | When developing new features you will need to recompile following any |
|
188 | 188 | changes made to the CSS or JavaScript files when developing the code:: |
|
189 | 189 | |
|
190 | 190 | grunt watch |
|
191 | 191 | |
|
192 | 192 | This prepares the development (with comments/whitespace) versions of files. |
|
193 | 193 | |
|
194 | 194 | Start the Development Servers |
|
195 | 195 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
196 | 196 | |
|
197 | 197 | From the rhodecode-vcsserver directory, start the development server in another |
|
198 | 198 | nix-shell, using the following command:: |
|
199 | 199 | |
|
200 | 200 | pserve configs/dev.ini |
|
201 | 201 | |
|
202 | 202 | In the adjacent nix-shell which you created for your development server, you may |
|
203 | 203 | now start CE with the following command:: |
|
204 | 204 | |
|
205 | 205 | |
|
206 | 206 | pserve --reload configs/dev.ini |
|
207 | 207 | |
|
208 | 208 | .. note:: |
|
209 | 209 | |
|
210 | 210 | `--reload` flag will automatically reload the server when source file changes. |
|
211 | 211 | |
|
212 | 212 | |
|
213 | 213 | Run the Environment Tests |
|
214 | 214 | ^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
215 | 215 | |
|
216 | 216 | Please make sure that the tests are passing to verify that your environment is |
|
217 | 217 | set up correctly. RhodeCode uses py.test to run tests. |
|
218 | 218 | While your instance is running, start a new nix-shell and simply run |
|
219 | 219 | ``make test`` to run the basic test suite. |
|
220 | 220 | |
|
221 | 221 | |
|
222 | 222 | Need Help? |
|
223 | 223 | ^^^^^^^^^^ |
|
224 | 224 | |
|
225 | 225 | Join us on Slack via https://rhodecode.com/join or post questions in our |
|
226 | 226 | Community Portal at https://community.rhodecode.com |
@@ -1,112 +1,113 b'' | |||
|
1 | 1 | .. _rhodecode-release-notes-ref: |
|
2 | 2 | |
|
3 | 3 | Release Notes |
|
4 | 4 | ============= |
|
5 | 5 | |
|
6 | 6 | |RCE| 4.x Versions |
|
7 | 7 | ------------------ |
|
8 | 8 | |
|
9 | 9 | .. toctree:: |
|
10 | 10 | :maxdepth: 1 |
|
11 | 11 | |
|
12 | release-notes-4.11.5.rst | |
|
12 | 13 | release-notes-4.11.4.rst |
|
13 | 14 | release-notes-4.11.3.rst |
|
14 | 15 | release-notes-4.11.2.rst |
|
15 | 16 | release-notes-4.11.1.rst |
|
16 | 17 | release-notes-4.11.0.rst |
|
17 | 18 | release-notes-4.10.6.rst |
|
18 | 19 | release-notes-4.10.5.rst |
|
19 | 20 | release-notes-4.10.4.rst |
|
20 | 21 | release-notes-4.10.3.rst |
|
21 | 22 | release-notes-4.10.2.rst |
|
22 | 23 | release-notes-4.10.1.rst |
|
23 | 24 | release-notes-4.10.0.rst |
|
24 | 25 | release-notes-4.9.1.rst |
|
25 | 26 | release-notes-4.9.0.rst |
|
26 | 27 | release-notes-4.8.0.rst |
|
27 | 28 | release-notes-4.7.2.rst |
|
28 | 29 | release-notes-4.7.1.rst |
|
29 | 30 | release-notes-4.7.0.rst |
|
30 | 31 | release-notes-4.6.1.rst |
|
31 | 32 | release-notes-4.6.0.rst |
|
32 | 33 | release-notes-4.5.2.rst |
|
33 | 34 | release-notes-4.5.1.rst |
|
34 | 35 | release-notes-4.5.0.rst |
|
35 | 36 | release-notes-4.4.2.rst |
|
36 | 37 | release-notes-4.4.1.rst |
|
37 | 38 | release-notes-4.4.0.rst |
|
38 | 39 | release-notes-4.3.1.rst |
|
39 | 40 | release-notes-4.3.0.rst |
|
40 | 41 | release-notes-4.2.1.rst |
|
41 | 42 | release-notes-4.2.0.rst |
|
42 | 43 | release-notes-4.1.2.rst |
|
43 | 44 | release-notes-4.1.1.rst |
|
44 | 45 | release-notes-4.1.0.rst |
|
45 | 46 | release-notes-4.0.1.rst |
|
46 | 47 | release-notes-4.0.0.rst |
|
47 | 48 | |
|
48 | 49 | |RCE| 3.x Versions |
|
49 | 50 | ------------------ |
|
50 | 51 | |
|
51 | 52 | .. toctree:: |
|
52 | 53 | :maxdepth: 1 |
|
53 | 54 | |
|
54 | 55 | release-notes-3.8.4.rst |
|
55 | 56 | release-notes-3.8.3.rst |
|
56 | 57 | release-notes-3.8.2.rst |
|
57 | 58 | release-notes-3.8.1.rst |
|
58 | 59 | release-notes-3.8.0.rst |
|
59 | 60 | release-notes-3.7.1.rst |
|
60 | 61 | release-notes-3.7.0.rst |
|
61 | 62 | release-notes-3.6.1.rst |
|
62 | 63 | release-notes-3.6.0.rst |
|
63 | 64 | release-notes-3.5.2.rst |
|
64 | 65 | release-notes-3.5.1.rst |
|
65 | 66 | release-notes-3.5.0.rst |
|
66 | 67 | release-notes-3.4.1.rst |
|
67 | 68 | release-notes-3.4.0.rst |
|
68 | 69 | release-notes-3.3.4.rst |
|
69 | 70 | release-notes-3.3.3.rst |
|
70 | 71 | release-notes-3.3.2.rst |
|
71 | 72 | release-notes-3.3.1.rst |
|
72 | 73 | release-notes-3.3.0.rst |
|
73 | 74 | release-notes-3.2.3.rst |
|
74 | 75 | release-notes-3.2.2.rst |
|
75 | 76 | release-notes-3.2.1.rst |
|
76 | 77 | release-notes-3.2.0.rst |
|
77 | 78 | release-notes-3.1.1.rst |
|
78 | 79 | release-notes-3.1.0.rst |
|
79 | 80 | release-notes-3.0.2.rst |
|
80 | 81 | release-notes-3.0.1.rst |
|
81 | 82 | release-notes-3.0.0.rst |
|
82 | 83 | |
|
83 | 84 | |RCE| 2.x Versions |
|
84 | 85 | ------------------ |
|
85 | 86 | |
|
86 | 87 | .. toctree:: |
|
87 | 88 | :maxdepth: 1 |
|
88 | 89 | |
|
89 | 90 | release-notes-2.2.8.rst |
|
90 | 91 | release-notes-2.2.7.rst |
|
91 | 92 | release-notes-2.2.6.rst |
|
92 | 93 | release-notes-2.2.5.rst |
|
93 | 94 | release-notes-2.2.4.rst |
|
94 | 95 | release-notes-2.2.3.rst |
|
95 | 96 | release-notes-2.2.2.rst |
|
96 | 97 | release-notes-2.2.1.rst |
|
97 | 98 | release-notes-2.2.0.rst |
|
98 | 99 | release-notes-2.1.0.rst |
|
99 | 100 | release-notes-2.0.2.rst |
|
100 | 101 | release-notes-2.0.1.rst |
|
101 | 102 | release-notes-2.0.0.rst |
|
102 | 103 | |
|
103 | 104 | |RCE| 1.x Versions |
|
104 | 105 | ------------------ |
|
105 | 106 | |
|
106 | 107 | .. toctree:: |
|
107 | 108 | :maxdepth: 1 |
|
108 | 109 | |
|
109 | 110 | release-notes-1.7.2.rst |
|
110 | 111 | release-notes-1.7.1.rst |
|
111 | 112 | release-notes-1.7.0.rst |
|
112 | 113 | release-notes-1.6.0.rst |
@@ -1,232 +1,232 b'' | |||
|
1 | 1 | # |
|
2 | 2 | # About |
|
3 | 3 | # ===== |
|
4 | 4 | # |
|
5 | 5 | # This file defines jobs for our CI system and the attribute "build" is used |
|
6 | 6 | # as the input for packaging. |
|
7 | 7 | # |
|
8 | 8 | # |
|
9 | 9 | # CI details |
|
10 | 10 | # ========== |
|
11 | 11 | # |
|
12 | 12 | # This file defines an attribute set of derivations. Each of these attributes is |
|
13 | 13 | # then used in our CI system as one job to run. This way we keep the |
|
14 | 14 | # configuration for the CI jobs as well under version control. |
|
15 | 15 | # |
|
16 | 16 | # Run CI jobs locally |
|
17 | 17 | # ------------------- |
|
18 | 18 | # |
|
19 | 19 | # Since it is all based on normal Nix derivations, the jobs can be tested |
|
20 | 20 | # locally with a run of "nix-build" like the following example: |
|
21 | 21 | # |
|
22 | 22 | # nix-build release.nix -A test-api -I vcsserver=~/rhodecode-vcsserver |
|
23 | 23 | # |
|
24 | 24 | # Note: Replace "~/rhodecode-vcsserver" with a path where a clone of the |
|
25 | 25 | # vcsserver resides. |
|
26 | 26 | |
|
27 | 27 | { pkgs ? import <nixpkgs> {} |
|
28 | 28 | , doCheck ? true |
|
29 | 29 | }: |
|
30 | 30 | |
|
31 | 31 | let |
|
32 | 32 | |
|
33 | 33 | inherit (pkgs) |
|
34 | 34 | stdenv |
|
35 | 35 | system; |
|
36 | 36 | |
|
37 | 37 | testing = import <nixpkgs/nixos/lib/testing.nix> { |
|
38 | 38 | inherit system; |
|
39 | 39 | }; |
|
40 | 40 | |
|
41 | 41 | runInMachine = testing.runInMachine; |
|
42 | 42 | |
|
43 | 43 | sphinx = import ./docs/default.nix {}; |
|
44 | 44 | |
|
45 | 45 | mkDocs = kind: stdenv.mkDerivation { |
|
46 | 46 | name = kind; |
|
47 | 47 | srcs = [ |
|
48 | 48 | (./. + (builtins.toPath "/${kind}")) |
|
49 | 49 | (builtins.filterSource |
|
50 | 50 | (path: type: baseNameOf path == "VERSION") |
|
51 | 51 | ./rhodecode) |
|
52 | 52 | ]; |
|
53 | 53 | sourceRoot = kind; |
|
54 | 54 | buildInputs = [ sphinx ]; |
|
55 | 55 | configurePhase = null; |
|
56 | 56 | buildPhase = '' |
|
57 | 57 | make SPHINXBUILD=sphinx-build html |
|
58 | 58 | ''; |
|
59 | 59 | installPhase = '' |
|
60 | 60 | mkdir -p $out |
|
61 | 61 | mv _build/html $out/ |
|
62 | 62 | |
|
63 | 63 | mkdir -p $out/nix-support |
|
64 | 64 | echo "doc manual $out/html index.html" >> \ |
|
65 | 65 | "$out/nix-support/hydra-build-products" |
|
66 | 66 | ''; |
|
67 | 67 | }; |
|
68 | 68 | |
|
69 | 69 | enterprise = import ./default.nix { |
|
70 | 70 | inherit |
|
71 | 71 | pkgs; |
|
72 | 72 | |
|
73 | 73 | # TODO: for quick local testing |
|
74 | 74 | doCheck = false; |
|
75 | 75 | }; |
|
76 | 76 | |
|
77 | 77 | test-cfg = stdenv.mkDerivation { |
|
78 | 78 | name = "test-cfg"; |
|
79 | 79 | unpackPhase = "true"; |
|
80 | 80 | buildInputs = [ |
|
81 | 81 | enterprise.src |
|
82 | 82 | ]; |
|
83 | 83 | installPhase = '' |
|
84 | 84 | mkdir -p $out/etc |
|
85 | 85 | cp ${enterprise.src}/test.ini $out/etc/enterprise.ini |
|
86 | 86 | # TODO: johbo: Needed, so that the login works, this causes |
|
87 | 87 | # probably some side effects |
|
88 | 88 | substituteInPlace $out/etc/enterprise.ini --replace "is_test = True" "" |
|
89 | 89 | |
|
90 | 90 | # Gevent configuration |
|
91 | 91 | cp $out/etc/enterprise.ini $out/etc/enterprise-gevent.ini; |
|
92 | 92 | cat >> $out/etc/enterprise-gevent.ini <<EOF |
|
93 | 93 | |
|
94 | 94 | [server:main] |
|
95 | 95 | use = egg:gunicorn#main |
|
96 | 96 | worker_class = gevent |
|
97 | 97 | EOF |
|
98 | 98 | |
|
99 | 99 | cp ${enterprise.src}/vcsserver/test.ini $out/etc/vcsserver.ini |
|
100 | 100 | ''; |
|
101 | 101 | }; |
|
102 | 102 | |
|
103 | 103 | ac-test-drv = import ./acceptance_tests { |
|
104 | 104 | withExternals = false; |
|
105 | 105 | }; |
|
106 | 106 | |
|
107 | 107 | # TODO: johbo: Currently abusing buildPythonPackage to make the |
|
108 | 108 | # needed environment for the ac-test tools. |
|
109 | 109 | mkAcTests = { |
|
110 | 110 | # Path to an INI file which will be used to run Enterprise. |
|
111 | 111 | # |
|
112 | 112 | # Intended usage is to provide different configuration files to |
|
113 | 113 | # run the tests against a different configuration. |
|
114 | 114 | enterpriseCfg ? "${test-cfg}/etc/enterprise.ini" |
|
115 | 115 | |
|
116 | 116 | # Path to an INI file which will be used to run the VCSServer. |
|
117 | 117 | , vcsserverCfg ? "${test-cfg}/etc/vcsserver.ini" |
|
118 | 118 | }: pkgs.pythonPackages.buildPythonPackage { |
|
119 | 119 | name = "enterprise-ac-tests"; |
|
120 | 120 | src = ./acceptance_tests; |
|
121 | 121 | |
|
122 | 122 | buildInputs = with pkgs; [ |
|
123 | 123 | curl |
|
124 | 124 | enterprise |
|
125 | 125 | ac-test-drv |
|
126 | 126 | ]; |
|
127 | 127 | |
|
128 | 128 | buildPhase = '' |
|
129 | 129 | cp ${enterpriseCfg} enterprise.ini |
|
130 | 130 | |
|
131 | 131 | echo "Creating a fake home directory" |
|
132 | 132 | mkdir fake-home |
|
133 | 133 | export HOME=$PWD/fake-home |
|
134 | 134 | |
|
135 | 135 | echo "Creating a repository directory" |
|
136 | 136 | mkdir repos |
|
137 | 137 | |
|
138 | 138 | echo "Preparing the database" |
|
139 |
|
|
|
139 | rc-setup-app \ | |
|
140 | 140 | --user=admin \ |
|
141 | 141 | --email=admin@example.com \ |
|
142 | 142 | --password=secret \ |
|
143 | 143 | --api-key=9999999999999999999999999999999999999999 \ |
|
144 | 144 | --force-yes \ |
|
145 | 145 | --repos=$PWD/repos \ |
|
146 | 146 | enterprise.ini > /dev/null |
|
147 | 147 | |
|
148 | 148 | echo "Starting rc-server" |
|
149 | 149 | vcsserver --config ${vcsserverCfg} >vcsserver.log 2>&1 & |
|
150 | 150 | rc-server enterprise.ini >rc-server.log 2>&1 & |
|
151 | 151 | |
|
152 | 152 | while ! curl -f -s http://localhost:5000 > /dev/null |
|
153 | 153 | do |
|
154 | 154 | echo "Waiting for server to be ready..." |
|
155 | 155 | sleep 3 |
|
156 | 156 | done |
|
157 | 157 | echo "Webserver is ready." |
|
158 | 158 | |
|
159 | 159 | echo "Starting the test run" |
|
160 | 160 | py.test -c example.ini -vs --maxfail=5 tests |
|
161 | 161 | |
|
162 | 162 | echo "Kill rc-server" |
|
163 | 163 | kill %2 |
|
164 | 164 | kill %1 |
|
165 | 165 | ''; |
|
166 | 166 | |
|
167 | 167 | # TODO: johbo: Use the install phase again once the normal mkDerivation |
|
168 | 168 | # can be used again. |
|
169 | 169 | postInstall = '' |
|
170 | 170 | mkdir -p $out |
|
171 | 171 | cp enterprise.ini $out |
|
172 | 172 | cp ${vcsserverCfg} $out/vcsserver.ini |
|
173 | 173 | cp rc-server.log $out |
|
174 | 174 | cp vcsserver.log $out |
|
175 | 175 | |
|
176 | 176 | mkdir -p $out/nix-support |
|
177 | 177 | echo "report config $out enterprise.ini" >> $out/nix-support/hydra-build-products |
|
178 | 178 | echo "report config $out vcsserver.ini" >> $out/nix-support/hydra-build-products |
|
179 | 179 | echo "report rc-server $out rc-server.log" >> $out/nix-support/hydra-build-products |
|
180 | 180 | echo "report vcsserver $out vcsserver.log" >> $out/nix-support/hydra-build-products |
|
181 | 181 | ''; |
|
182 | 182 | }; |
|
183 | 183 | |
|
184 | 184 | vcsserver = import <vcsserver> { |
|
185 | 185 | inherit pkgs; |
|
186 | 186 | |
|
187 | 187 | # TODO: johbo: Think of a more elegant solution to this problem |
|
188 | 188 | pythonExternalOverrides = self: super: (enterprise.myPythonPackagesUnfix self); |
|
189 | 189 | }; |
|
190 | 190 | |
|
191 | 191 | runTests = optionString: (enterprise.override (attrs: { |
|
192 | 192 | doCheck = true; |
|
193 | 193 | name = "test-run"; |
|
194 | 194 | buildInputs = attrs.buildInputs ++ [ |
|
195 | 195 | vcsserver |
|
196 | 196 | ]; |
|
197 | 197 | checkPhase = '' |
|
198 | 198 | py.test ${optionString} -vv -ra |
|
199 | 199 | ''; |
|
200 | 200 | buildPhase = attrs.shellHook; |
|
201 | 201 | installPhase = '' |
|
202 | 202 | echo "Intentionally not installing anything" |
|
203 | 203 | ''; |
|
204 | 204 | meta.description = "Enterprise test run ${optionString}"; |
|
205 | 205 | })); |
|
206 | 206 | |
|
207 | 207 | jobs = { |
|
208 | 208 | |
|
209 | 209 | build = enterprise; |
|
210 | 210 | |
|
211 | 211 | # johbo: Currently this is simply running the tests against the sources. Nicer |
|
212 | 212 | # would be to run xdist and against the installed application, so that we also |
|
213 | 213 | # cover the impact of installing the application. |
|
214 | 214 | test-api = runTests "rhodecode/api"; |
|
215 | 215 | test-functional = runTests "rhodecode/tests/functional"; |
|
216 | 216 | test-rest = runTests "rhodecode/tests --ignore=rhodecode/tests/functional"; |
|
217 | 217 | test-full = runTests "rhodecode"; |
|
218 | 218 | |
|
219 | 219 | docs = mkDocs "docs"; |
|
220 | 220 | |
|
221 | 221 | aggregate = pkgs.releaseTools.aggregate { |
|
222 | 222 | name = "aggregated-jobs"; |
|
223 | 223 | constituents = [ |
|
224 | 224 | jobs.build |
|
225 | 225 | jobs.test-api |
|
226 | 226 | jobs.test-rest |
|
227 | 227 | jobs.docs |
|
228 | 228 | ]; |
|
229 | 229 | }; |
|
230 | 230 | }; |
|
231 | 231 | |
|
232 | 232 | in jobs |
General Comments 0
You need to be logged in to leave comments.
Login now