fork of https://github.com/Mailu/Mailu/
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
6bed48e2ac
2427: Switch ci/cd workflow to use local build cache for buildx r=mergify[bot] a=Diman0
## What type of PR?
enhancement
## What does this PR do?
Switch to local build cache, cached via actions/cache@v3
The previous method of using gha cache via buildx proved to be unreliable. Using a local cache via actions/cache@v3 is much more reliable. The build job will re-use cache from previous workflow runs.
The total workflow time is still similar ~12 minutes.
If the cache action does intermittently seem to have issues with slow download, we can configure a lower timeout. It is now set on the default 60 minutes.
Some important tidbits:
Cache fragment in build step:
```
- name: Configure actions/cache@v3 action for storing build cache in the /tmp/cache folder
uses: actions/cache@v3
with:
path: /tmp/cache/${{ matrix.target }}
key: ${{ github.ref }}-${{ inputs.mailu_version }}-${{ matrix.target }}-${{ github.run_id }}
restore-keys: |
${{ github.ref }}-${{ inputs.mailu_version }}-${{ matrix.target }}
```
- actions/cache will never update a cache. So on cache-hit (key is found), the cache will not be updated.
- To workaround this, it is possible to use a key that will not have a cache hit. And use restore-keys to lookup and load an existing cache. `${{ github.ref }}-${{ inputs.mailu_version }}-${{ matrix.target }}` matches with `${{ github.ref }}-${{ inputs.mailu_version }}-${{ matrix.target }}-${{ github.run_id }}`.
- So this will result the cache being loaded from a previous workflow. For more info see https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#example-using-multiple-restore-keys
- Two jobs cannot write to the same cache simultaneously. If two jobs (in the same workflow or between workflows) access the same cache (key), then only one of the two workflows can update the cache. For this reason the cache key used in the build step must be unique.
- ${{ inputs.mailu_version }} is used to make sure x64 and arm do not access each others build cache.
Unfortunately it is not possible to use a for loop to loop through steps. For this reason it is not possible possible to shorten the amount of action/Cache@v3 steps. The only possibility is to create our own [composite action](https://docs.github.com/en/actions/creating-actions/creating-a-composite-action). But this makes it maybe to complex. Then the action.yml of the composite action must be maintained as well.
## Prerequisites
Before we can consider review and merge, please make sure the following list is done and checked.
If an entry in not applicable, you can check it or remove it from the list.
- [n/a] In case of feature or enhancement: documentation updated accordingly
- [n/a] Unless it's docs or a minor change: add [changelog](https://mailu.io/master/contributors/workflow.html#changelog) entry file.
Co-authored-by: Dimitri Huisman <diman@huisman.xyz>
|
2 years ago | |
|---|---|---|
| .github | 2 years ago | |
| core | 2 years ago | |
| design | 2 years ago | |
| docs | 2 years ago | |
| optional | 2 years ago | |
| setup | 2 years ago | |
| tests | 2 years ago | |
| towncrier | 2 years ago | |
| webmails | 2 years ago | |
| .gitignore | 5 years ago | |
| .mergify.yml | 2 years ago | |
| AUTHORS.md | 2 years ago | |
| CHANGELOG.md | 2 years ago | |
| CODE_OF_CONDUCT.md | 7 years ago | |
| CONTRIBUTING.md | 4 years ago | |
| ISSUE_TEMPLATE.md | 4 years ago | |
| LICENSE.md | 8 years ago | |
| PULL_REQUEST_TEMPLATE.md | 3 years ago | |
| README.md | 2 years ago | |
| RELEASE_TEMPLATE.md | 2 years ago | |
| SECURITY.md | 2 years ago | |
| bors.toml | 3 years ago | |
| pyproject.toml | 5 years ago | |
README.md
Mailu is a simple yet full-featured mail server as a set of Docker images. It is free software (both as in free beer and as in free speech), open to suggestions and external contributions. The project aims at providing people with an easily setup, easily maintained and full-featured mail server while not shipping proprietary software nor unrelated features often found in popular groupware.
Most of the documentation is available on our Website, you can also try our demo server before setting up your own, and come talk to us on Matrix.
Features
Main features include:
- Standard email server, IMAP and IMAP+, SMTP and Submission with autoconfiguration profiles for clients
- Advanced email features, aliases, domain aliases, custom routing
- Web access, multiple Webmails and administration interface
- User features, aliases, auto-reply, auto-forward, fetched accounts
- Admin features, global admins, announcements, per-domain delegation, quotas
- Security, enforced TLS, DANE, MTA-STS, Letsencrypt!, outgoing DKIM, anti-virus scanner
- Antispam, auto-learn, greylisting, DMARC and SPF
- Freedom, all FOSS components, no tracker included
Contributing
Mailu is free software, open to suggestions and contributions. All components are free software and compatible with the MIT license. All specific configuration files, Dockerfiles and code are placed under the MIT license.