Skip to content

Commit 2aaa08a

Browse files
author
Dennis Labordus
committed
Added info about creating a release.
Signed-off-by: Dennis Labordus <[email protected]>
1 parent 19d9272 commit 2aaa08a

File tree

5 files changed

+139
-67
lines changed

5 files changed

+139
-67
lines changed

docs/DEVELOPING.md

Lines changed: 3 additions & 67 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@
1313
What's GitHub? It's where you're looking right now! (Joking!).
1414

1515
We are using GitHub for hosting our Git repositories. GitHub is being used for creating issues and creating Pull
16-
Requests to review / merge each others code.
16+
Requests to review / merge each other's code.
1717

1818
### LFX Security Tool
1919
For checking potential security issues, we use the [LFX Security Tool](https://security.lfx.linuxfoundation.org/#/e8b6fdf9-2686-44c5-bbaa-6965d04ad3e1/licenses).
@@ -33,7 +33,7 @@ Every GIT repository can build its artifacts and publish these to GitHub Package
3333
Other GIT repositories can then add GitHub Packages as Maven repository to their build tool.
3434
See below how to do both action for the specific tools.
3535

36-
To use GitHub Packages a username and token is needed. The username is your GitHub username. The token can be generate
36+
To use GitHub Packages a username and token is needed. The username is your GitHub username. The token can be generated
3737
in GitHub by going to your settings, Developer settings, Personal access tokens.
3838
Generate a new token here and make sure that the scope "read:packages" is enabled. Use this token below to configure the build tools.
3939

@@ -105,70 +105,6 @@ $ mvn package eclipse:eclipse
105105

106106
After importing the projects with either method, install SonarLint for quicker feedback on potential sonar issues.
107107

108-
## GitHub Actions
109-
110-
### Settings.xml during GitHub Action for GitHub Packages
111-
During multiple GitHub Actions (like building and SonarCloud analysis), the custom `settings.xml` file is needed because it needs access to the GitHub Packages
112-
to download certain artifacts. We can do this by adding the following step **before** the GitHub Packages repository is needed.
113-
114-
```yaml
115-
- name: Create custom Maven Settings.xml
116-
uses: whelk-io/maven-settings-xml-action@v18
117-
with:
118-
output_file: custom_maven_settings.xml
119-
servers: '[{ "id": "github-packages-compas", "username": "OWNER", "password": "${{ secrets.GITHUB_TOKEN }}" }]'
120-
```
121-
122-
This basically creates a custom `settings.xml` at location `custom_maven_settings.xml`. This file can be passed to maven in the next step
123-
by using `mvn -s custom_maven_settings.xml` and perhaps some extra parameters you wish for.
124-
125-
For the `servers` part, we again have the `github-packages-compas` ID that needs to be the same. We have an `OWNER` username (this is the default, because
126-
it needs to have a username) and a password which is the GITHUB_TOKEN that's always available.
127-
128-
## Releasing software
129-
130-
### Create a release
131-
132-
To create a release of the software we are using the release functionality of GitHub. Under the tab 'code' there is a section
133-
'Releases'. When selected all current releases will be displayed, and a new release can be created (draft release).
134-
The standard branch to create a release from should be the "main" branch, so the code changes have been reviewed.
135-
136-
For every repository that creates a software product (artifacts or docker images) a GitHub Action ('release-project.yml')
137-
is defined. This action runs when a release is created.
138-
```yaml
139-
on:
140-
release:
141-
types: [released]
142-
```
143-
144-
Depending on the type of project different steps will be executed.
145-
Common steps are:
146-
- Checking out the source code,
147-
- Extracting the entered version from the Git Tag.
148-
- Set version using Maven
149-
- Setup Maven settings.xml file
150-
151-
Depending on the type of project other steps will be executed. Some examples are:
152-
- Build and publish the software to GitHub Packages using Maven
153-
- Build and publish the docker image to DockerHub using Maven
154-
- Build and publish the docker image to DockerHub using NPM and Docker
155-
156-
### Publish artifacts using Maven
157-
158-
To publish artifacts to GiHub Packages a distribution section needs to be added to pom.xml of the root.
159-
```xml
160-
<distributionManagement>
161-
<repository>
162-
<id>github-packages-compas</id>
163-
<name>GitHub Packages</name>
164-
<url>https://maven.pkg.github.com/com-pas/[repo-name]</url>
165-
</repository>
166-
</distributionManagement>
167-
```
168-
The ID is the same as the ID used for the repository section [above](#github-packages-in-maven).
169-
This way the same credentials will be used to connect to GitHub Packages as described [above](#maven-local-settingsxml-for-github-packages).
170-
Replace "[repo-name]" with the name of the repository from CoMPAS.
171-
172108
## Others
173109

174110
### Adding custom badges to your README
@@ -183,4 +119,4 @@ In case of the LFX Security Tool, we used the following:
183119
- Insert 'LFX Security Tool' as the label.
184120
- Insert the API to use, in case of our LFX Security tool projects we use [this API](https://api.security.lfx.linuxfoundation.org/v1/project/e8b6fdf9-2686-44c5-bbaa-6965d04ad3e1/issues).
185121
- Now you can query using JsonPath. To get all open high issues from the 'CoMPAS Core' project, use `issues[?(@['repository-name'] == 'compas-core')]['high-open-issues']`.
186-
- Choose a color and a pre- or surfix text.
122+
- Choose a color and a pre- or suffix text.

docs/GITHUB_ACTIONS.md

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,24 @@ More to follow.
1212

1313
Github Actions are configured using YAML files. These files are stored in the `.github/workflows` directory of a specific repository.
1414

15+
## Maven settings.xml during GitHub Action for GitHub Packages
16+
During multiple GitHub Actions (like building and SonarCloud analysis), the custom `settings.xml` file is needed because it needs access to the GitHub Packages
17+
to download certain artifacts. We can do this by adding the following step **before** the GitHub Packages repository is needed.
18+
19+
```yaml
20+
- name: Create custom Maven Settings.xml
21+
uses: whelk-io/maven-settings-xml-action@v18
22+
with:
23+
output_file: custom_maven_settings.xml
24+
servers: '[{ "id": "github-packages-compas", "username": "OWNER", "password": "${{ secrets.GITHUB_TOKEN }}" }]'
25+
```
26+
27+
This basically creates a custom `settings.xml` at location `custom_maven_settings.xml`. This file can be passed to maven in the next step
28+
by using `mvn -s custom_maven_settings.xml` and perhaps some extra parameters you wish for.
29+
30+
For the `servers` part, we again have the `github-packages-compas` ID that needs to be the same. We have an `OWNER` username (this is the default, because
31+
it needs to have a username) and a password which is the GITHUB_TOKEN that's always available.
32+
1533
## Building
1634
All source code repositories need some kind of building step.
1735
By default, all source code repositories use Maven as the build tool.

docs/PULL_REQUESTS.md

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# Pull requests
2+
3+
To add code to the different repositories the code is build in a feature branch and merged back to the branch ``develop``
4+
using a pull request. No direct committing is allowed to the branches ``develop`` and ``main``.
5+
When a release is created the branch ``develop`` is merged to the branch ``main`` using a pull request.
6+
In some repositories the branch ``develop`` is skipped and not there. Feature branches are merged directly to the branch
7+
``develop``
8+
9+
## Creating a pull request
10+
11+
When creating a pull request to merge a feature branch back we need to be aware that some information about the pull
12+
request is used to generate the release notes.
13+
14+
- **Title**: The title is added to the release notes, so give it a nice descriptive one.
15+
- **Labels**: Use a label to add the pull request to correct section in the release notes.
16+
- ``enhancement``: The pull request adds as a new feature.
17+
- ``bug``: The pull request solves a bugfix.
18+
- ``tooling``: Change or update to tooling used to build project.
19+
20+
There is a special label ``dependencies`` used by dependabot for updating dependencies.
21+
These are grouped together in a separate section.
22+
If no label is added the pull request will be added to the section ``Other Changes`` at the bottom of the release notes.
23+
24+
The following labels cause the pull request to be ignored in the release notes:
25+
- ``wontfix``
26+
- ``duplicate``
27+
- ``invalid``

docs/RELEASES.md

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
# Releasing software
2+
3+
## Create a release
4+
5+
To create a release of the software we are using the release functionality of GitHub. Under the tab ``code`` there is a section
6+
``Releases`` (Right side). When selected all current releases will be displayed, and a new release can be created (draft release).
7+
The standard branch to create a release from should be the ``main`` branch.
8+
9+
Enter the following values when creating a new release:
10+
- **Choose a tag**: Enter a new version using semantic versioning, for example ``0.1.4``.
11+
Also press ``Create new tag`` to create the new label.
12+
- **Target**: This should normally be ``main``.
13+
- **Release title**: Name of the release, use the following template ``Release <tag> of <project name>``, for instance
14+
``Release 0.1.4 of SCL Auto Alignment Service``
15+
- **Describe the release**: These are the release notes, press the button ``Auto-generate release notes`` to generate these.
16+
Check [Configure release notes generation](#configure-release-notes-generation) to configure how these are generated.
17+
18+
Now press ``Publish release`` to create the release. For every repository that creates a software product (artifacts or docker images)
19+
a GitHub Action (``release-project.yml``) is defined. This action runs when a release is created.
20+
```yaml
21+
on:
22+
release:
23+
types: [released]
24+
```
25+
26+
Depending on the type of project different steps will be executed.
27+
Common steps are:
28+
- Checking out the source code,
29+
- Extracting the entered version from the Git Tag.
30+
- Set version using Maven
31+
- Setup Maven settings.xml file
32+
33+
Depending on the type of project other steps will be executed. Some examples are:
34+
- Build and publish the software to GitHub Packages using Maven
35+
- Build and publish the docker image to DockerHub using Maven
36+
- Build and publish the docker image to DockerHub using NPM and Docker
37+
38+
## Publish artifacts using Maven
39+
40+
To publish artifacts to GiHub Packages a distribution section needs to be added to pom.xml of the root.
41+
```xml
42+
<distributionManagement>
43+
<repository>
44+
<id>github-packages-compas</id>
45+
<name>GitHub Packages</name>
46+
<url>https://maven.pkg.github.com/com-pas/[repo-name]</url>
47+
</repository>
48+
</distributionManagement>
49+
```
50+
The ID is the same as the ID used for the repository section in [Maven Build](DEVELOPING.md#github-packages-in-maven).
51+
This way the same credentials will be used to connect to GitHub Packages as described [Maven Build](DEVELOPING.md#maven-local-settingsxml-for-github-packages).
52+
Replace ``[repo-name]`` with the name of the repository from CoMPAS.
53+
54+
## Configure release notes generation
55+
56+
During creating of a release we will use the GitHub feature to automatically generate the release notes using the pull requests.
57+
The way these release notes are created can be configured by adding/updating the file ``release.yml`` to the directory ``.github``.
58+
59+
The content of the file ``release.yml`` is currently:
60+
```yaml
61+
changelog:
62+
exclude:
63+
labels:
64+
- wontfix
65+
- duplicate
66+
- invalid
67+
categories:
68+
- title: New Features
69+
labels:
70+
- enhancement
71+
- title: Bugfixes
72+
labels:
73+
- bug
74+
- title: Tooling changes
75+
labels:
76+
- tooling
77+
- title: Dependency updates
78+
labels:
79+
- dependencies
80+
- title: Other Changes
81+
labels:
82+
- "*"
83+
```
84+
85+
This will group different pull request using the different labels.

docs/_includes/sidebar.html

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,12 @@ <h2>
2727
<li class="nav-list-item">
2828
<a class="sidebar-nav-item{% if page.url == '/GITHUB_ACTIONS.html' %} active{% endif %}" href="{{ site.baseurl }}/GITHUB_ACTIONS.html">Github Actions</a>
2929
</li>
30+
<li class="nav-list-item">
31+
<a class="sidebar-nav-item{% if page.url == '/PULL_REQUESTS.html' %} active{% endif %}" href="{{ site.baseurl }}/PULL_REQUESTS.html">Pull requests</a>
32+
</li>
33+
<li class="nav-list-item">
34+
<a class="sidebar-nav-item{% if page.url == '/RELEASES.html' %} active{% endif %}" href="{{ site.baseurl }}/RELEASES.html">Releasing software</a>
35+
</li>
3036
<li class="nav-list-item">
3137
<a class="sidebar-nav-item{% if page.url == '/DEPENDABOT.html' %} active{% endif %}" href="{{ site.baseurl }}/DEPENDABOT.html">Dependabot</a>
3238
</li>

0 commit comments

Comments
 (0)