| Commit message (Collapse) | Author | Age |
|
|
|
| |
See https://github.com/NixOS/nixpkgs/pull/93883 for further details.
|
|
|
|
|
|
|
|
|
|
| |
1) Building with the sandbox enabled is the standard on Linux,
so it is of little relevance with distribution they are using.
Because of this, we now specify "Linux" instead of "NixOS",
and the sandbox checkbox specifies "non-Linux".
2) aarch64 is a much more common platform, so we add two separate
checkboxes for both aarch64-linux and aarch64-darwin.
3) The platform names now match what is actually used by Nix.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* build(deps): bump zeebe-io/backport-action
Bumps [zeebe-io/backport-action](https://github.com/zeebe-io/backport-action) from 2b994724142df0774855690db56bc6308fb99ffa to 0.0.5. This release includes the previously tagged commit.
- [Release notes](https://github.com/zeebe-io/backport-action/releases)
- [Commits](https://github.com/zeebe-io/backport-action/compare/2b994724142df0774855690db56bc6308fb99ffa...e5d4d7c39c94b65670847d11d259b2f574fa3d30)
---
updated-dependencies:
- dependency-name: zeebe-io/backport-action
dependency-type: direct:production
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [cachix/cachix-action](https://github.com/cachix/cachix-action) from 9 to 10.
- [Release notes](https://github.com/cachix/cachix-action/releases)
- [Commits](https://github.com/cachix/cachix-action/compare/v9...v10)
---
updated-dependencies:
- dependency-name: cachix/cachix-action
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
* ci: add no-channel check
* Update .github/workflows/no-channel.yml
Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
|
|\
| |
| | |
GHA: add basic eval checks
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The project has moved away from Freenode as an IRC network[1], and there
is now a quite large channel on Libera. As such, we should point users
towards that instead.
This also changes all examples to refer to libera instead of freenode
as, with the recent deletion of all freenode channels, it is perhaps
where most communities are to be found nowadays.
Finally, also link to the official Matrix room[2] as an alternative to
IRC.
Related: https://github.com/NixOS/nixpkgs/pull/129384
[1]: https://discourse.nixos.org/t/join-us-on-matrix-at-nix-nixos-org-migrating-from-freenode
[2]: https://github.com/NixOS/rfcs/pull/94
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By generalizing the previous merge-staging action we can support a large
number of branch pairs that need to be merged periodically.
Provide two intervals, daily and every six hours, to accomodate
different needs.
Co-Authored-By: Malte Brandy <malte.brandy@maralorn.de>
|
|
|
|
|
|
|
| |
We found that many users found it difficult to locate this document.
Github supports it in the root, see:
https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors
|
|
|
|
|
|
|
| |
Automation tools should instruct their users clearly what tasks are still on the user.
Updates the bot's version to get the `pull_description` feature:
https://github.com/zeebe-io/backport-action/pull/64
|
|
|
|
| |
Also delete empty release notes file.
|
|\
| |
| | |
direct-push action: delay to workaround eventually consistent DB
|
| | |
|
|\ \
| | |
| | | |
backport action: run only when the label starts with 'backport'
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| | |
It only works sometimes and we're unable to fix it.
|
|\ \
| | |
| | | |
php: Improve extensions meta and codeowner data
|
| | | |
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
I am maintaining out-of-tree PHP expressions (https://github.com/fossar/nix-phps)
so I would like to get notified of changes of the code I depend on,
even though I cannot commit to becoming a PHP maintaintainer at the moment.
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
require approval
|
| |
|
| |
|
| |
|
|
|
|
| |
This is consistent with the other actions.
|
|
|
|
|
| |
We have this set in the other actions, it prevents the action from
running in PRs made against forks.
|
|
|
|
| |
Adds three more valid branches to the rebase action.
|
|\
| |
| | |
Add backporting action
|
| | |
|
| |
| |
| | |
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
|
| |
| |
| | |
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
|
| |
| |
| |
| |
| |
| | |
If "backport <branch>" label is applied to a PR,
once the PR is merged, github-actions bot will create another PR targeting
<branch> and cherry-picking commits.
|
| |
| |
| |
| |
| | |
We have this set in the other actions, it prevents the action from
running in PRs made against forks.
|
|\ \
| |/
|/| |
CODEOWNERS: merge the neovim lines as they are not additive
|
| |
| |
| |
| |
| |
| |
| | |
CODEOWNERS files always take that *last* match for a specific match.
Having two lines for the same path will only ever result in the last
line being used. The intention here was that both of these individuals
are owners of the neovim space and not just one.
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove elements of the PR template that have a low signal/noise ratio,
and add one that I think would have a good signal/noise ratio.
-----
Remove:
Determined the impact on package closure size (by running `nix path-info
-S` before and after)
-----
Rationale:
This is rarely done in practice, and apart from for specific packages
this is usually not a good indicator of anything useful
It might make sense to re-introduce it with two holes to fill, but then
we would have to make a serious decision to never land without these two
numbers filled in or with too big a regression, because in practice this
box has been a no-op in many cases.
Maybe just integrating this check in nixpkgs-review would bring the most
benefit here?
-----
-----
Remove:
Ensured that relevant documentation is up to date
-----
Rationale:
This is fuzzy, “relevant documentation” is way too often hard to find
-----
-----
Add:
Added a release notes entry if the change is major or breaking
-----
Rationale:
This is way too often forgotten, and is also a self-contained easy task
-----
|