Infrastructure Issues issueshttps://gitlab.dune-project.org/infrastructure/issues0/-/issues2024-02-28T16:09:24Zhttps://gitlab.dune-project.org/infrastructure/issues0/-/issues/72Mail test2024-02-28T16:09:24ZSantiago Ospina De Los Ríossospinar@gmail.comMail test@ansgar @markus.blatt@ansgar @markus.blatthttps://gitlab.dune-project.org/infrastructure/issues0/-/issues/69inter-module dependencies for merge-requests2023-02-16T21:07:39ZChristian Engwerinter-module dependencies for merge-requestsIf submitting a merge-request that requires a certain feature from an other module, which is not yet merged, our ci-tools currently support some heuristic to switch in all modules to the branch name of the MR, if this branch exists. Othe...If submitting a merge-request that requires a certain feature from an other module, which is not yet merged, our ci-tools currently support some heuristic to switch in all modules to the branch name of the MR, if this branch exists. Otherwise master is used (if I understood everything correctly).
It would be nice if we could make this behaviour more flexible.
1. it would be nice if the heuristics follow the branch graph, so that an MR for a release branch uses the corresponding release branches of the other modules (perhaps this already works somehow?!)
2. it would be helpful if we could add somewhere some meta-data to the MR, which might then include hints on which branches to use for the dependencies.https://gitlab.dune-project.org/infrastructure/issues0/-/issues/67Change default branch name from master to main2022-03-08T16:30:02ZSimon PraetoriusChange default branch name from master to main## Summary
We have decided in the developer meeting 2022 to switch the default branch name from `master` to `main`, but only if the effort is reasonable. This issue collects the necessary steps and procedures to do such a transition.
We...## Summary
We have decided in the developer meeting 2022 to switch the default branch name from `master` to `main`, but only if the effort is reasonable. This issue collects the necessary steps and procedures to do such a transition.
We are in no rush and thus can prepare and discuss this transition before taking any steps.
### Reasons for Renaming?
- The default branch name in *GitLab* and *GitHub* has changed to `main`.
- Whenever you create a new project, the instructions tell you to create a `main` branch.
- The online Git introductions start to change to `main`.
- In teaching we are using `main` as the default branch.
- Git has started to make `main` the new default branch.
- The name `master` branch might be deprecated/removed as default branch name from git in the future.
- Some projects already use `main` and thus we have mixed names, resulting in some complications, e.g., with `dunecontrol git checkout master`.
- The original reasoning can be summarized, see, e.g., [Why-GitHub-renamed-its-master-branch-to-main](https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main) or [Software freedom conservancy](https://sfconservancy.org/news/2020/jun/23/gitbranchname/)
Note, a project is not required to make this change. It is a project-wise decision. We might do this change for all core/staging/extensions modules at once. The steps illustrated below should be provided as scripts. With a little effort, we can make this process (nearly) completely automatic.
### How to rename `master` branch to `main`?
Each repository has to do the following steps:
1. `git checkout master` (checkout the current master, maybe followed by `git pull` to be up-to-date)
2. `git branch -m master main` (create a new `main` branch locally, taking the history of `master`)
3. `git push -u origin main` (push the new local main branch to the remote repo)
4. `git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main` (switch the current HEAD to the main branch)
5. In `GitLab -> Project Settings -> Repository -> Default branch`, choose `main`
6. In `GitLab -> Project Settings -> Repository -> Protected branches`, protect the new `main` branch similar to the old `master` branch
7. unprotect the `master` branch
8. `git push origin --delete master` (delete the master branch on the remote)
### What does the user need to do?
In order to update local repositories, all users need to do the following steps:
1. `git checkout master` (Switch to the `master` branch)
2. `git branch -m master main` (create a new `main` branch locally, taking the history of `master`)
3. `git fetch` (Get the latest commits (and branches!) from the remote)
4. `git branch --unset-upstream` (Remove the existing tracking connection with `origin/master`)
5. `git branch -u origin/main` (Create a new tracking connection with the new `origin/main` branch)
6. `git config --global init.defaultBranch main`
### What else need to be updated?
1. All merge-requests with target branch `master` need to be set to `main`
2. In `.gitlab-ci.yml` includes of other projects `.yml` files with branch reference must be updated
3. Any reference to a specific `master` branch, e.g., in installation instructions and other git howto's must be updated.
4. Maybe external repository mirrors? This could be fine.
I think, step 1 can be scripted using the Gitlab-API, tested already in an example repo. If all `.gitlab-ci.yml` files are written in a similar style, the second step could also be scripted. Alternatively, we do not delete the `master` branch in the `config-ci` repository right away, to allow a slow transition. For step 3 we need to inspect our docs. Not sure how many of such references exist.
### Possible issues?
- If local git installation is older than 2.28 one cannot easily set a default branch for new projects, because `master` is somewhere hard coded in the templates. There are workaround, see e.g. [superuser.com](https://superuser.com/questions/1419613/change-git-init-default-branch-name)
- Hard coded references to files in the master branch git directory are hard to spot. Maybe a `grep` over all repositories can help
- I'm not sure whether it is a good idea to have for a transition period both, `master` and `main`. But maybe it is possible, at least for the download. We should search for a way to have the `master` branch be synchronized with the `main` in this case.https://gitlab.dune-project.org/infrastructure/issues0/-/issues/66CI jobs have connection problems with docker daemon2021-07-30T18:03:53ZMarkus BlattCI jobs have connection problems with docker daemonHave been experiencing this often this week: testing succeeds and then the job fails with
```
ERROR: Job failed (system failure): Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
```
Usual...Have been experiencing this often this week: testing succeeds and then the job fails with
```
ERROR: Job failed (system failure): Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
```
Usually it works after retrying a few times.https://gitlab.dune-project.org/infrastructure/issues0/-/issues/58Reduce runner occupation by introducing workflow rules.2020-12-07T09:38:38ZRobert KReduce runner occupation by introducing workflow rules.With gitlab CI it's easy to add workflow rules to only trigger pipelines for certain events.
This way one can avoid to start pipelines for branches that are not ready to even start the pipeline etc.
A simple workflow could be to run pi...With gitlab CI it's easy to add workflow rules to only trigger pipelines for certain events.
This way one can avoid to start pipelines for branches that are not ready to even start the pipeline etc.
A simple workflow could be to run pipelines only when a merge request for a branch exists and when the merge does into the master (and releases). To do this the following lines have to be added to .gtilab-ci.yml
```
workflow:
rules:
- if: $CI_MERGE_REQUEST_ID # Execute jobs in merge request context
- if: $CI_COMMIT_BRANCH == 'master' # Execute jobs when a new commit is pushed to master branch
```
One could go even further and only trigger the pipelines when the merge request is not in WIP state.
```
workflow:
rules:
- if: '$CI_MERGE_REQUEST_ID && $CI_MERGE_REQUEST_TITLE !~ /^WIP/' # Execute jobs in merge request context and not in WIP status
- if: $CI_COMMIT_BRANCH == 'master' # Execute jobs when a new commit is pushed to master branch
```
The only downside here is that once the WIP is resolved then the pipelines are triggered on the next commit/push.
The CI can, btw, also be omitted manually by added -o ci.skip to the push command:
```
git push -o ci.skip origin branch_name
```
So the question is: Should we introduce this for the core modules.https://gitlab.dune-project.org/infrastructure/issues0/-/issues/57Gitlab Access Rights for extension modules2020-04-01T13:17:24ZRené HeßGitlab Access Rights for extension modules**Reason of this issue**:
Some people (that shouldn't have them) have `owner` access rights in `extension` modules
I think I know what happened and will try to revert it. The goal of this issue is to have some place where it is documen...**Reason of this issue**:
Some people (that shouldn't have them) have `owner` access rights in `extension` modules
I think I know what happened and will try to revert it. The goal of this issue is to have some place where it is documented. Then we can point people here in case something goes wrong ;). Thanks to @nils.dreier for pointing out the issue.
**What happened**:
Two weeks ago @andreas.dedner wrote a mail to the dune-devel mailinglist where he pointed out, that extension and staging modules should have more core developers as owner. I first tried to give access rights to all extension modules to all members of the group `core`. Unfortunately this lead to the situation that `developer` of `core` got `owner` rights in extension modules. I removed this group access and handed out individual access rights to the core developers.
Removing the group access unfortunately didn't remove the `owner` access for everyone. I thought it works since the access rights do not show up in the extension group or the individual module but apparently the user still has them. Since the access right doesn't show up correctly you can't simply remove them. Trying around showed that removing people from the core group and adding them again seems to do the trick. This whole issue sounds like a gitlab bug to me and I will report it there ;)
**What will I do next**
I will remove all non-core-developer from the core group and add them again with the same rights as before. I hope that everyone has the correct access rights afterwards. If not you can comment here or write me a mail.https://gitlab.dune-project.org/infrastructure/issues0/-/issues/56Runner hd-2c-8g-1h / slave02.parcomp is broken2019-01-28T18:17:33ZJö Fahlkejorrit@jorrit.deRunner hd-2c-8g-1h / slave02.parcomp is brokenJobs https://gitlab.dune-project.org/core/dune-common/-/jobs/79795 and https://gitlab.dune-project.org/core/dune-common/-/jobs/79827 failed with:
```
ERROR: Job failed (system failure): Cannot connect to the Docker daemon at tcp://slave0...Jobs https://gitlab.dune-project.org/core/dune-common/-/jobs/79795 and https://gitlab.dune-project.org/core/dune-common/-/jobs/79827 failed with:
```
ERROR: Job failed (system failure): Cannot connect to the Docker daemon at tcp://slave02.parcomp:2376. Is the docker daemon running?
```
Job https://gitlab.dune-project.org/core/dune-common/-/jobs/79828 failed with:
```
ERROR: Job failed (system failure): Error response from daemon: Conflict. The container name "/runner-c87abe34-project-133-concurrent-0-predefined-0" is already in use by container "8f8d3649155e29ff13e826684581d3199ed3d2376915ff4a39f2f77bd1d2faa0". You have to remove (or rename) that container to be able to reuse that name.
```Steffen Müthingsteffen.muething@iwr.uni-heidelberg.deSteffen Müthingsteffen.muething@iwr.uni-heidelberg.dehttps://gitlab.dune-project.org/infrastructure/issues0/-/issues/50https for lists.dune-project.org2018-10-01T12:27:28ZJö Fahlkejorrit@jorrit.dehttps for lists.dune-project.orgThis issue is for tracking the migration of http://lists.dune-project.org to https://lists.dune-project.org
It is under infrastructure, since the [dune-lists-doc](https://gitlab.dune-project.org/infrastructure/dune-lists-doc) repository...This issue is for tracking the migration of http://lists.dune-project.org to https://lists.dune-project.org
It is under infrastructure, since the [dune-lists-doc](https://gitlab.dune-project.org/infrastructure/dune-lists-doc) repository is internal.Jö Fahlkejorrit@jorrit.deJö Fahlkejorrit@jorrit.dehttps://gitlab.dune-project.org/infrastructure/issues0/-/issues/45[CI] Wanted: build configuration without MPI2017-11-08T15:32:28ZJö Fahlkejorrit@jorrit.de[CI] Wanted: build configuration without MPI@ansgar Is it possible to get at least one build configuration that does not include MPI? That would uncover bugs like core/dune-common!372 sooner.
(The cmake variable to disable MPI would be `-DCMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE`).@ansgar Is it possible to get at least one build configuration that does not include MPI? That would uncover bugs like core/dune-common!372 sooner.
(The cmake variable to disable MPI would be `-DCMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE`).https://gitlab.dune-project.org/infrastructure/issues0/-/issues/43Re-enable GitLab registration once they get their act together2017-06-01T09:48:45ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deRe-enable GitLab registration once they get their act togetherGitLab managed to break the system hook that tells gitlabresponder about new users. As a consequence, our user vetting procedure is completely broken.
I have disabled user registration for now and added a note telling people to send an ...GitLab managed to break the system hook that tells gitlabresponder about new users. As a consequence, our user vetting procedure is completely broken.
I have disabled user registration for now and added a note telling people to send an email to the admins instead.
As soon as [GitLab Issue #31547](https://gitlab.com/gitlab-org/gitlab-ce/issues/31547) is fixed, we should turn it on agin.Steffen Müthingsteffen.muething@iwr.uni-heidelberg.deSteffen Müthingsteffen.muething@iwr.uni-heidelberg.dehttps://gitlab.dune-project.org/infrastructure/issues0/-/issues/36[Doxygen] Grid Capabilities Table is not parsed2017-10-30T23:36:14ZJanick Gerstenberger[Doxygen] Grid Capabilities Table is not parsedsee https://www.dune-project.org/doxygen/master/group__Grid.html#Grid22see https://www.dune-project.org/doxygen/master/group__Grid.html#Grid22https://gitlab.dune-project.org/infrastructure/issues0/-/issues/32When should the CI or tests fail?2017-10-30T23:36:14ZCarsten Gräsergraeser@math.fau.deWhen should the CI or tests fail?The CI turned out to be really great, in order to check the status of our modules. However, it seems that there is no clear consensus on its purpose. At several occasions people (me included) mentioned that a continuously failing CI is a...The CI turned out to be really great, in order to check the status of our modules. However, it seems that there is no clear consensus on its purpose. At several occasions people (me included) mentioned that a continuously failing CI is annoying because it defeats its purpose to easily reveal if a commit or MR breaks code. This especially happens for long standing bugs and known issues making people suggest to disable those tests. On the other hand it's clearly not the purpose of the CI to give us a good feeling just by being green and a failing CI has its value because it documents a defect.
In order to avoid increasing discontent we should decide on a general guideline how to deal with this.https://gitlab.dune-project.org/infrastructure/issues0/-/issues/20Gitlab hook shows error messages when pushing to a repository with submodules2018-03-19T04:54:28ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deGitlab hook shows error messages when pushing to a repository with submodulesThe push is accepted, but it shows an error message:
```
Counting objects: 42, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (42/42), done.
Writing objects: 100% (42/42), 6.65 KiB | 0 bytes/s, done.
Tot...The push is accepted, but it shows an error message:
```
Counting objects: 42, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (42/42), done.
Writing objects: 100% (42/42), 6.65 KiB | 0 bytes/s, done.
Total 42 (delta 31), reused 0 (delta 0)
remote: fatal: git cat-file: could not get object info
remote: fatal: git cat-file: could not get object info
remote: fatal: git cat-file: could not get object info
To ssh://git@conan2.iwr.uni-heidelberg.de:20022/dominic/my-repo.git
875bb3e..7a9fbcd master -> master
```https://gitlab.dune-project.org/infrastructure/issues0/-/issues/15Make https://gitlab.dune-project.org/dashboard/issues publically viewable2020-05-14T19:10:12ZMarkus BlattMake https://gitlab.dune-project.org/dashboard/issues publically viewableCurrently it is not possible to link to a bug tracker that contains all bugs in DUNE. The canonical choice would be https://gitlab.dune-project.org/dashboard/issues. Unfortunately, this page is currently not viewable if one is not logged...Currently it is not possible to link to a bug tracker that contains all bugs in DUNE. The canonical choice would be https://gitlab.dune-project.org/dashboard/issues. Unfortunately, this page is currently not viewable if one is not logged in.
IMHO it would make sense to make this page viewable and change the link to the old flyspray instance on our page to this one.https://gitlab.dune-project.org/infrastructure/issues0/-/issues/7Please change gitlab entry page and default redirect.2017-10-30T23:36:14ZMarkus BlattPlease change gitlab entry page and default redirect.When opening gitlab.dune-project.org and non-existing pages, e.g. https://gitlab.dune-project.org/projects, one always gets redirected to the sign-in page https://gitlab.dune-project.org/users/sign_in. This page is not very informative a...When opening gitlab.dune-project.org and non-existing pages, e.g. https://gitlab.dune-project.org/projects, one always gets redirected to the sign-in page https://gitlab.dune-project.org/users/sign_in. This page is not very informative and it is impossible to go somewhere reasonable from there without a login.
It would be great if somebody would find the time to change the default page to e.g. https://gitlab.dune-project.org/groups/core. I would assume that this would be an improvement. (Unforntunately, https://gitlab.dune-project.org/groups/ requires a login).