Difference between revisions of "Git Repositories"
Luca.frosini (Talk | contribs) (→Configure the newly created repository) |
|||
| (14 intermediate revisions by 3 users not shown) | |||
| Line 10: | Line 10: | ||
https://code-repo.d4science.org/gCubeSystem/myNewRepo.git | https://code-repo.d4science.org/gCubeSystem/myNewRepo.git | ||
| − | = | + | = Operating a Repository = |
| − | + | It's recommended to use, for the day to day operations - clone, pull, push - the ssh protocol instead of the https one. ssh does not have size limits on the upload operations, the user does not have to provide username and password, it also works when the web interface is not working for whatever reason. | |
| − | + | Every user can add one or more public SSH keys from their profile. A PGP public key can also be provided, and then used to sign commits and pull requests. | |
| − | + | = Configure the newly created Repository = | |
| − | + | ||
| − | + | In the same settings panel where you made the repository public, you must configure the '''Advanced Settings''' section (see figure below). | |
| − | + | == Wiki == | |
| + | Set the wiki as enabled and external, and give the URL of the remote wiki page. | ||
| + | The '''Wiki''' tab in Gitea repository will open a new browser tab to the linked wiki page. | ||
| − | + | == Issue Tracker == | |
| + | Set issue tracker as enabled and external, then configure as follows: | ||
| + | * ''External Issue Tracker URL'': The URL must be something like https://support.d4science.org/projects/gcube/issues. You should get the browser URL of a query which filters as much possible the issue(s) related to the component. Actually, the best way is filtering on the sprint your component belongs to. The '''Issues''' tab in Gitea repository will open a new browser tab to the linked query. | ||
| + | ** External Issue Tracker URL Format: MUST be https://support.d4science.org/issues/{index} | ||
| + | * External Issue Tracker Number Format: '''Numeric''' | ||
| − | + | Upon these settings, Gitea is capable of properly linking to the issues indicated as [#TICKET_NUMBER] in any markdown file (e.g. CHANGELOG.md) as well as for any reference made as #TICKET_NUMBER in the commit message. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | == Pull Requests == | ||
| + | Enable the pull requests (note: this setting will be available after the first commit into the repository) | ||
You can eventually force the use of pull requests from the ''Branches'' settings tab. | You can eventually force the use of pull requests from the ''Branches'' settings tab. | ||
| + | This picture shows a typical configuration for a repository: | ||
[[File:RepositoryAdvancedSettings.png]] | [[File:RepositoryAdvancedSettings.png]] | ||
| − | + | = Initialize an empty Repository = | |
| − | + | ||
If the repository belongs to a new project (i.e. it is not [[Import_from_SVN|imported]]), on the developer machine: | If the repository belongs to a new project (i.e. it is not [[Import_from_SVN|imported]]), on the developer machine: | ||
<source lang="bash"> | <source lang="bash"> | ||
| Line 50: | Line 51: | ||
It is strongly recommended that each repository has a README.md (in Markdown format) in the root folder and each significant subfolder. The README should briefly explain the content of the repository, how to build it and link the related wiki documentation. | It is strongly recommended that each repository has a README.md (in Markdown format) in the root folder and each significant subfolder. The README should briefly explain the content of the repository, how to build it and link the related wiki documentation. | ||
| − | + | = Add an existing Repository = | |
On the developer machine, in the root folder of the repository, add the new remote to the configuration and then push the entire repository in the master branch: | On the developer machine, in the root folder of the repository, add the new remote to the configuration and then push the entire repository in the master branch: | ||
<source lang="bash"> | <source lang="bash"> | ||
| Line 56: | Line 57: | ||
git push -u origin master | git push -u origin master | ||
</source> | </source> | ||
| + | |||
| + | = Mirroring a Repository to GitHub = | ||
| + | |||
| + | Gitea now natively supports mirroing its repositories into another git service. The documentation to setup a push mirror is https://docs.gitea.io/en-us/repo-mirror/#setting-up-a-push-mirror-from-gitea-to-github | ||
| + | |||
| + | '''TODO:''' decide the user (or the users) to use, github side | ||
''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ''Back to the [[Continuous_Integration_procedure_(2019) | CI guide]].'' | ||
[[Category:Continuous_Integration]] | [[Category:Continuous_Integration]] | ||
Latest revision as of 16:29, 1 October 2021
Contents
Create a New Repository
From the web interface, click on the New Repository button:
- Make sure the owner is the organization
- Create the repo as public
The name of the repository must be the name of the artifactID in the root POM (lowercase separated by dashes) and it is created within the gCubeSystem organization, the repo URL is:
https://code-repo.d4science.org/gCubeSystem/myNewRepo.git
Operating a Repository
It's recommended to use, for the day to day operations - clone, pull, push - the ssh protocol instead of the https one. ssh does not have size limits on the upload operations, the user does not have to provide username and password, it also works when the web interface is not working for whatever reason.
Every user can add one or more public SSH keys from their profile. A PGP public key can also be provided, and then used to sign commits and pull requests.
Configure the newly created Repository
In the same settings panel where you made the repository public, you must configure the Advanced Settings section (see figure below).
Wiki
Set the wiki as enabled and external, and give the URL of the remote wiki page. The Wiki tab in Gitea repository will open a new browser tab to the linked wiki page.
Issue Tracker
Set issue tracker as enabled and external, then configure as follows:
- External Issue Tracker URL: The URL must be something like https://support.d4science.org/projects/gcube/issues. You should get the browser URL of a query which filters as much possible the issue(s) related to the component. Actually, the best way is filtering on the sprint your component belongs to. The Issues tab in Gitea repository will open a new browser tab to the linked query.
- External Issue Tracker URL Format: MUST be https://support.d4science.org/issues/{index}
- External Issue Tracker Number Format: Numeric
Upon these settings, Gitea is capable of properly linking to the issues indicated as [#TICKET_NUMBER] in any markdown file (e.g. CHANGELOG.md) as well as for any reference made as #TICKET_NUMBER in the commit message.
Pull Requests
Enable the pull requests (note: this setting will be available after the first commit into the repository) You can eventually force the use of pull requests from the Branches settings tab.
This picture shows a typical configuration for a repository:
Initialize an empty Repository
If the repository belongs to a new project (i.e. it is not imported), on the developer machine:
touch README.md git init git add README.md git commit -m "first commit" git remote add origin https://code-repo.d4science.org/gCubeSystem/myNewRepo.git git push -u origin master
It is strongly recommended that each repository has a README.md (in Markdown format) in the root folder and each significant subfolder. The README should briefly explain the content of the repository, how to build it and link the related wiki documentation.
Add an existing Repository
On the developer machine, in the root folder of the repository, add the new remote to the configuration and then push the entire repository in the master branch:
git remote add origin https://code-repo.d4science.org/gCubeSystem/myNewRepo.git git push -u origin master
Mirroring a Repository to GitHub
Gitea now natively supports mirroing its repositories into another git service. The documentation to setup a push mirror is https://docs.gitea.io/en-us/repo-mirror/#setting-up-a-push-mirror-from-gitea-to-github
TODO: decide the user (or the users) to use, github side
Back to the CI guide.
