You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Generate Workspace using Gita
This change adds the capability to generate a workspace directly from the known_good.json file. To achieve this, the known_good.json file is transformed into a configuration file for a git workspace management tool called gita, which is then used to check out all mentioned modules on the specific commit/branch that is given in known_good.json. In addition, the score_modules.MODULE.bazel is updated with local_path_overrides to the checked out modules. Hence, a bazel build will immediately work as expected.
# Conflicts:
# .gitignore
# Conflicts:
# .devcontainer/devcontainer.json
* also generate .gitmodules metadata
* Remove git submodules generation
This does not work, since submodules require also commit tracking in the top-level repository. This would by default pollute reference_integration, which is certainly not what we want.
* do not create a workspace by default
* Add VSCode Tasks and documentation
* Fix deprecation warning
* mark as executable
* clarify the devcontainer relation and which build targets should be working
You can obtain a complete S-CORE workspace, i.e. a git checkout of all modules from `known_good.json`, on the specific branches / commits, integrated into one Bazel build.
63
+
This helps with cross-module development, debugging, and generally "trying out things".
64
+
65
+
> [!NOTE]
66
+
> The startup of the [S-CORE devcontainer](https://github.com/eclipse-score/devcontainer)[integrated in this repository](.devcontainer/) already installs supported workspace managers and generates the required metadata.
67
+
> You can do this manually as well, of course (e.g. if you do not use the devcontainer).
68
+
> Take a look at `.devcontainer/prepare_workspace.sh`, which contains the setup script.
69
+
70
+
> [!NOTE]
71
+
> Not all Bazel targets are supported yet.
72
+
> Running `./scripts/integration_test.sh` will work, though.
73
+
> Take a look at the [Known Issues](#known-issues-️) below to see which Bazel targets are available and working.
74
+
75
+
The supported workspace managers are:
76
+
77
+
| Name | Description |
78
+
|------|-------------|
79
+
|[Gita](https://github.com/nosarthur/gita)| "a command-line tool to manage multiple git repos" |
80
+
81
+
A description of how to use these workspace managers, together with their advantages and drawbacks, is beyond the scope of this document.
82
+
In case of doubt, choose the first.
83
+
84
+
### Initialization of the workspace
85
+
86
+
> [!WARNING]
87
+
> This will change the file `score_modules.MODULE.bazel`.
88
+
> Do **not** commit these changes!
89
+
90
+
1. Switch to local path overrides, using the VSCode Task (`Terminal`->`Run Task...`) "Switch Bazel modules to `local_path_overrides`".
91
+
Note that you can switch back to `git_overrides` (the default) using the task "Switch Bazel modules to `git_overrides`"
92
+
93
+
2. Run VSCode Task "<Name>: Generate workspace", e.g. "Gita: Generate workspace".
94
+
This will clone all modules using the chosen workspace manager.
95
+
The modules will be in sub-directories starting with `score_`.
96
+
Note that the usage of different workspace managers is mutually exclusive.
97
+
98
+
When you now run Bazel, it will use the local working copies of all modules and not download them from git remotes.
99
+
You can make local changes to each module, which will be directly reflected in the next Bazel run.
0 commit comments