@@ -103,6 +103,8 @@ Starting a Developer Container
103
103
104
104
sed -i ~ /.config/containers/containers.conf -e ' /label=false/d' -e ' /^\[containers\]$/a label=false'
105
105
106
+ Preparation
107
+ ~~~~~~~~~~~
106
108
107
109
For this section we will work with the ADSimDetector Generic IOC that we
108
110
used in previous tutorials. Let's go and fetch a version of the Generic IOC
@@ -146,6 +148,31 @@ the container, you will need these commands if it fails to build.
146
148
147
149
ec ioc stop bl01t-ea-ioc-02
148
150
151
+ Launching the Developer Container
152
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
153
+
154
+ In the this section we are going to use vscode to launch a developer container.
155
+ This means that all vscode terminals and editors will be running inside a container
156
+ and accessing the container filesystem. This is a very convenient way to work
157
+ because it makes it possible to archive away the development environment
158
+ along side the source code. It also means that you can easily share the
159
+ development environment with other developers.
160
+
161
+ For epics-containers the generic IOC >>>is<<< the developer container. When
162
+ you build the developer target of the container in CI it will contain all the
163
+ build tools and dependencies needed to build the IOC. It will also contain
164
+ the IOC source code and the support module source code. For this reason
165
+ we can also use the same developer target image to make the developer
166
+ container itself. We then have an environment that encompasses all the
167
+ source you could want to change inside of a Generic IOC, and the
168
+ tools to build and test it.
169
+
170
+ It is also important to understand that although your vscode session is
171
+ entirely inside the container, some of your host folders have been mounted
172
+ into the container. This is done so that your important changes to source
173
+ code would not be lost if the container were rebuilt. See `container-layout `_
174
+ for details of which host folders are mounted into the container.
175
+
149
176
Once built, open the project in VSCode:
150
177
151
178
.. code-block :: bash
@@ -160,6 +187,19 @@ You should now be *inside* the container. All terminals started in VSCode will
160
187
be inside the container. Every file that you open with the VSCode editor
161
188
will be inside the container.
162
189
190
+
191
+ There are some caveats because some folders are mounted from the host file
192
+ system. For example, the ``ioc-adsimdetector `` project folder
193
+ is mounted into the container as a volume. It is mounted under
194
+ ``/epics/ioc-adsimdetector ``. This means that you can edit the source code
195
+ from your local machine and the changes will be visible inside the container and
196
+ outside the container. This is a good thing as you should consider the container
197
+ filesystem to be a temporary filesystem that will be destroyed when the container
198
+ is rebuilt or deleted.
199
+
200
+ Preparing the IOC for Testing
201
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
202
+
163
203
.. note ::
164
204
165
205
Troubleshooting: if you are experiencing problems with the devcontainer you
@@ -170,16 +210,6 @@ will be inside the container.
170
210
171
211
rm -rf ~ /.vscode/* ~ /.vscode-server/*
172
212
173
-
174
- There are some caveats because some folders are mounted from the host file
175
- system. For example, the ``ioc-adsimdetector `` project folder
176
- is mounted into the container as a volume. It is mounted under
177
- ``/epics/ioc-adsimdetector ``. This means that you can edit the source code
178
- from your local machine and the changes will be visible inside the container and
179
- outside the container. This is a good thing as you should consider the container
180
- filesystem to be a temporary filesystem that will be destroyed when the container
181
- is deleted.
182
-
183
213
Now that you are *inside * the container you have access to the tools built into
184
214
it, this includes ``ibek ``. The first command you should run is:
185
215
0 commit comments