* Update README.md
* We don't want to use the netbox-community pull-request template
* Update container building workflow
* Only build amd64 images
* Add our 'oxcert' branch as equivalent to upstream's 'release' branch
* Tag the version of the container as OxCERT's modification
This is just for the netbox container: the underlying netbox version
will come from upstream
* Build own own images and push to ghcr.io
* Only build amd64 images
* Only push images to GitHub Container Registry for the OxCERT organization
* Refer to our private copy in the GitHub Container Registry ghcr.io
* Use ghcr.io/oxcert/netbox for all netbox images
Build and push to this repo. Read from it with docker-compose
* Make releases relative to the 'oxcert' branch
rather than upstream's 'release' branch. This is a different workflow
than used in any of our other repos, where PRs, changes, etc. are
first merged into a 'develop' branch, and the release process is to
merge accumulated changes into the main 'oxcert' branch.
Tag names for releases should follow whatever upstream is using with
"-oxcert" appended.
* Re-add the pull-request template
But in a very cut-down form. We don't have an issue tracker on this
repo, and we assume the intentions and motivations for any PR will
have been discussed within the team already. We do, however, want all
PRs to be against the 'develop' branch, in parallel to upstream's
workflow.
* On second thoughts, set container version to 1.0.0
This is OxCERT's version 1.0.0 of the containerized Netbox image which
is basically the same as the 2.7.0 netbox-community equivalent.
* Fix typo from upstream
Function should have been called `git_rebase()` rather than
duplicating the name of `git_merge()`
* Another requirements file for pip to process
* Install the plugins requirements alongside the other python modules
* Build the netbox-plugin-dns plugin into our container images
So we end up with just the arm64 images in ghcr.io repository, since
they are the slowest to build.
Resynchronise the 'platforms' section in the workflow with
upstream. It's not a list of architectures, one per list entry. It's
a single list entry mentioning all architectures.
* Update README.md
* We don't want to use the netbox-community pull-request template
* Update container building workflow
* Only build amd64 images
* Add our 'oxcert' branch as equivalent to upstream's 'release' branch
* Tag the version of the container as OxCERT's modification
This is just for the netbox container: the underlying netbox version
will come from upstream
* Build own own images and push to ghcr.io
* Only build amd64 images
* Only push images to GitHub Container Registry for the OxCERT organization
* Refer to our private copy in the GitHub Container Registry ghcr.io
* Use ghcr.io/oxcert/netbox for all netbox images
Build and push to this repo. Read from it with docker-compose
* Make releases relative to the 'oxcert' branch
rather than upstream's 'release' branch. This is a different workflow
than used in any of our other repos, where PRs, changes, etc. are
first merged into a 'develop' branch, and the release process is to
merge accumulated changes into the main 'oxcert' branch.
Tag names for releases should follow whatever upstream is using with
"-oxcert" appended.
* Re-add the pull-request template
But in a very cut-down form. We don't have an issue tracker on this
repo, and we assume the intentions and motivations for any PR will
have been discussed within the team already. We do, however, want all
PRs to be against the 'develop' branch, in parallel to upstream's
workflow.
* On second thoughts, set container version to 1.0.0
This is OxCERT's version 1.0.0 of the containerized Netbox image which
is basically the same as the 2.7.0 netbox-community equivalent.
* Fix typo from upstream
Function should have been called `git_rebase()` rather than
duplicating the name of `git_merge()`
`z` is valid only for bindmounts
When using with volumes a warning for each volume appears:
netbox$ docker compose up
[+] Building 0.0s (0/0)
WARN[0000] mount of type `volume` should not define `bind` option
WARN[0000] mount of type `volume` should not define `bind` option
WARN[0000] mount of type `volume` should not define `bind` option
This may appear only when using a docker-compose.override.yml
