cd712e86b7 ci: attest results of guix builds (pasta)
Pull request description:
## Issue being fixed or feature implemented
This simply adds attestations to guix results by GitHub. This way, not only can someone verify that all us developers agree, but also that GitHub hosted runners agree :)
## What was done?
Add actions/attest-build-provenance to guix-build CI
## How Has This Been Tested?
see: https://github.com/PastaPastaPasta/dash/actions/runs/11239755631
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
UdjinM6:
utACK cd712e86b7
Tree-SHA512: b590ee2cf29aa57f78cb68c22d5327e8c9272d63d523c3b64fbbdffabb90981a6b6505c5f511bde19310ea1d8c96fc6d181359a7d7a0672612473110cbe079ef
770651aa15 set hosts in guix-check (pasta)
580bbe6d1c feat: improve guix building; run always, save artifacts (pasta)
101a31555f refactor: simplify caching setup, add a restore key to actually cache besides 1 run (pasta)
1b139e4837 feat: automatically run guix-build on all tags pushed (pasta)
Pull request description:
## Issue being fixed or feature implemented
Previously, we only ran guix on 1 machine for all hosts; this slowed it down a lot. Let's move to GitHub action runners, but run them all separately. Then upload the artifacts.
In the future there is significant caching I can add that should help a lot more. But currently, takes about 1 hour
## What was done?
## How Has This Been Tested?
see: https://github.com/PastaPastaPasta/dash/actions/runs/10345024600
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
UdjinM6:
utACK 770651aa15
Tree-SHA512: 639b95c3b6a26f205ed00c138a9189f915cfc36a815516035e59ceda82675414b1bd31a361b33449b5e4c58a7655f3a7d616b362c23f7fa75e72b1284be06b9e
9178e8a75f feat: add smob and provenance in release for dockerhub; use jammy; apt remove as possible (pasta)
Pull request description:
## Issue being fixed or feature implemented
Docker provenance refers to the origin and history of Docker images, including how they were built, modified, and by whom. An SBOM (Software Bill of Materials) is a detailed list of all components in a software application, providing transparency about libraries, dependencies, and versions used, which is crucial for security and compliance.
## What was done?
Add SBOM and provenance to docker build; this may allow some level of validation that GitHub actions is actually doing what it says it is.
See this for more information https://docs.docker.com/build/ci/github-actions/attestations/
## How Has This Been Tested?
Building with buildx with sbom and provenance flags locally
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
UdjinM6:
utACK 9178e8a75f
Tree-SHA512: 6e3f35a0b30f002e2d5d80d6dd18ee554a1c15c62c1d4cbe1185f38977f55a199998515cf5bb9a027670f068f3d56ef33faa062d8c4122a886375d00afe6bf2f
f1f994a122b135160216b6fc56c095b83eeaf812 doc: Add `guix` prefix for changes to reproducible builds (Hennadii Stepanov)
Pull request description:
Most of contributors already use the `guix:` prefix for changes to `contrib/guix`. Also `guix` is shorter than `build`, and it is more focused/specific.
ACKs for top commit:
fanquake:
ACK f1f994a122b135160216b6fc56c095b83eeaf812
Tree-SHA512: 3f754e80802ec4e871b099ce1f0877e34ecc4816fbe9c49bfd2a7368ef79fed9edf6c65f38eedef2a87367fdc911dc548e0def422d80b66a91ce2e5f35826032
## Issue being fixed or feature implemented
Client version string is inconsistent. Building `v20.0.0-beta.8` tag
locally produces binaries that report `v20.0.0-beta.8` version but
binaries built in guix would report
`v20.0.0rc1-g3e732a952226a20505f907e4fd9b3fdbb14ea5ee` instead. Building
any commit after `v20.0.0-beta.8` locally would result in versions like
`v20.0.0rc1-8c94153d2497` which is close but it's still yet another
format. And both versions with `rc1` in their names are confusing cause
you'd expect them to mention `beta.8` instead maybe (or is it just me?
:D ).
## What was done?
Change it so that the version string would look like this:
on tag: ~`v20.0.0-beta.8-dev` or `v20.0.0-beta.8-gitarc`~
`v20.0.0-beta.8`
post-tag: ~`v20.0.0-beta.8-1-gb837e08164-gitarc`~
`v20.0.0-beta.8-1-gb837e08164`
post-tag format is
`recent tag`-`commits since that tag`-`g+12 chars of commit hash`-`dirty
(optional)` ~-`dev or gitarc`~
~`dev`/`gitarc` suffixes should help avoiding confusion with the release
versions and they also indicate the way non-release binaries were
built.~
Note that release binaries do not use any of this, they still use
`PACKAGE_VERSION` from `configure` like before.
Also, `CLIENT_VERSION_RC` is no longer used in this setup so it was
removed.
Few things aren't clear to me yet:
1. Version bump in `configure.ac` no longer affects the reported version
(unless it's an actual release). Are there any downsides I might be
missing?
2. Which tag should we use on `develop` once we bump version in
configure? `v21.0.0-init`? `v21.0.0-alpha1`?
3. How is it going to behave once `merge master back into develop` kind
of PR is merged? E.g. say `develop` branch is on `v21.0.0-alpha1` tag
and we merge v20.1.0 from `master` back into it. Will this bring
`v20.1.0` release tag into `develop`? Will it become the one that will
be used from that moment? If so we will probably need another tag on
`develop` every time such PR is merged e.g. `v21.0.0-alpha2` (or
whatever the next number is).
Don't think these are blockers but would like to hear thoughts from
others.
## How Has This Been Tested?
Built binaries locally, built them using guix at a specific tag and at
some commit on top of it.
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
## What was done?
Add an echo
## How Has This Been Tested?
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
facef3d4131f9980a4516282f11731361559509c doc: Explain that anyone can work on good first issues, move text to CONTRIBUTING.md (MarcoFalke)
fae2fb2a196ee864e9a13fffc24a0279cd5d17e6 doc: Expand section on Getting Started (MarcoFalke)
100000d1b2c2e38d7a14a31b0af79e0e4316b04c doc: Add headings to CONTRIBUTING.md (MarcoFalke)
fab893e0caf510d4836a20194892ef9c71426c51 doc: Fix unrelated typos reported by codespell (MarcoFalke)
Pull request description:
Some random doc changes:
* Add sections to docs, so that they can be linked to
* Explain that anyone (even maintainers) are allowed to work on good first issues
* Expand section on Getting Started slightly
ACKs for top commit:
hebasto:
ACK facef3d4131f9980a4516282f11731361559509c
fanquake:
ACK facef3d4131f9980a4516282f11731361559509c
Tree-SHA512: 8998e273a76dbf4ca77e79374c14efe4dfcc5c6df6b7d801e1e1e436711dbe6f76b436f9cbc6cacb45a56827babdd6396f3bd376a9426ee7be3bb9b8a3b8e383
5f40d2770abc5c7f29182b4a64120150b2aad912 github: Add warning for bug reports (Wladimir J. van der Laan)
Pull request description:
I've noticed the "Bug" label being added redundantly fairly frequently. I think this might be due to github's templates.
All in all, the link in https://github.com/bitcoin/bitcoin/issues/new/choose to open a regular issue is a bit hidden from sight. Direct people's attention to it.
ACKs for top commit:
practicalswift:
ACK 5f40d2770abc5c7f29182b4a64120150b2aad912 - currently it is very easy to miss the tiny "Open a regular issue" link :)
jonasschnelli:
ACK 5f40d2770abc5c7f29182b4a64120150b2aad912
hebasto:
ACK 5f40d2770abc5c7f29182b4a64120150b2aad912
Tree-SHA512: e6c94c02f9f7d00621b580d406d03f8754173150bf456409ccc474b76fb93ff857ff4a0c652bf5c03d4f1b97ecf29ae0ff7bf8b763207f9c8522b8dcecc20109
## Issue being fixed or feature implemented
I was probably using `GITHUB_REPOSITORY` incorrectly, let's try it this
way
#5724 follow-up
## What was done?
## How Has This Been Tested?
n/a
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
Should hopefully fix
https://github.com/dashpay/dash-dev-branches/actions/runs/6939402277/job/18876687119#5716 follow-up
## What was done?
`$GITHUB_REPOSITORY` is not available inside docker, pass it inside
## How Has This Been Tested?
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
- Using `actions/cache` with a local buildx cache without the "move
cache" workaround will result in constant growth in cache size:
https://docs.docker.com/build/ci/github-actions/cache/#local-cache
## What was done?
- Docker natively supports the GHA Cache API, so we should use it for
faster and more efficient cache usage
- Actions were also bumped to current stable versions
## How Has This Been Tested?
Devs please test this by running a test Guix build from workflow
dispatch
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [x] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
- We want to enable use of the AWS-hosted GitHub Actions runners, now
that [corresponding
infra](https://github.com/dcginfra/tf-aws-gh-runner/pull/8/files#diff-ad98d33884a302f6c747dc6b326c6b3af3887f2ec25e0bd7a0395f10444818f3)
exists to deploy these runners
## What was done?
Add new labels and workflow dispatch button to allow runner testing
## How Has This Been Tested?
Pending testing in CI
## Breaking Changes
None
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e
tests
- [x] I have made corresponding changes to the documentation
- [ ] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
fa30d5282cb07b6de0160d7df8b649332db97dde doc: Remove label from good first issue template (MarcoFalke)
Pull request description:
Good first issues aren't that frequent that manually assigning the label is a problem, but this fixes the spam problem (e.g. https://twitter.com/GoodFirstIssues/status/1295455089491161088 )
ACKs for top commit:
jnewbery:
ACK fa30d5282cb07b6de0160d7df8b649332db97dde
Tree-SHA512: 59e7c707637cc328e2443c2b7e5d2c82ef151739ad5afb6cea1a60501318dc8c4c81c95591eed8172581ac99d43cf826dcdd547e096eff1038137853af67a975
## Issue being fixed or feature implemented
see warnings in https://github.com/dashpay/dash/actions/runs/5462770856
## What was done?
https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
## How Has This Been Tested?
n/a
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
1. not all binaries were covered with checksums
2. there were no checksums for archives
## What was done?
add missing checksums, also group and sort them
## How Has This Been Tested?
run commands after local guix build
see this PR results
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
Automated guix builds in CI when specifically requested
## What was done?
Any PR with the `build-guix` label added will automatically have the
Guix build ran and the hashes placed in the CI output to compare against
## How Has This Been Tested?
This PR
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that
apply._
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
small cleanups and improvements
## What was done?
pls see individual commits
## How Has This Been Tested?
see
https://github.com/dashpay/dash/actions/runs/4715728701/jobs/8362893373?pr=5330
## Breaking Changes
n/a
## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
## Issue being fixed or feature implemented
This adds a check that ensures branches merge cleanly into master via a
ff-only
## What was done?
Added a GitHub action created via gpt-4 :)
## How Has This Been Tested?
https://github.com/PastaPastaPasta/dash/actions/runs/4703432752/jobs/8341923994
and
https://github.com/PastaPastaPasta/dash/actions/runs/4703457936/jobs/8341980146
for expected pass and expected fail
## Breaking Changes
None, should be back ported to v19.x branch when we get the chance.
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
**For repository code-owners and collaborators only**
- [x] I have assigned this pull request to a milestone
fabca7756d6908ad581f3a699f1be6ecc9f62e03 doc: Add issue templates for bug and feature request (MarcoFalke)
Pull request description:
Fixes#16627
Can be tested via https://github.com/MarcoFalke/bitcoin/issues
ACKs for top commit:
jb55:
ACK fabca7756d6908ad581f3a699f1be6ecc9f62e03
fanquake:
ACK fabca7756d6908ad581f3a699f1be6ecc9f62e03
Tree-SHA512: 1ebe58f9c0110a9332adf1d80001cd9ed6fe60208e387c93b8564dc66821f753e34b23cb6f4cae45168024862ee884913976e132820b7a4759fa6391b0d1127c
## Issue being fixed or feature implemented
Currently template for "New pull request" have a lot of instruction that
are formatted as comments by html/markdown tag.
It makes this instruction to append in the final commit message when
pull request is merged because they are invisible for reviewer (marked
as comment).
With new template the messages would be more likely to be cleaned up
before merging.
## What was done?
Replaced commented text in template to cursive test (italic)
## How Has This Been Tested?
By clicking "Preview" on GitHub
## Breaking Changes
No breaking changes, it's trivial change
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have assigned this pull request to a milestone
* docs: indicate conventional commit syntax should be used for PRs
* feat: add config file for semantic PR GH app
Requires installation of https://probot.github.io/apps/semantic-pull-requests/
* docs: mention added backport type
* introduce handle_potential_conflicts.py to only warn on true conflicts. Fail CI when there is a conflict
Signed-off-by: Pasta <pasta@dashboost.org>
* remove unneeded input assign
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
* use dashpay instead of PastaPastaPasta
Signed-off-by: Pasta <pasta@dashboost.org>
* Update .github/workflows/handle_potential_conflicts.py
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
* more linter fixes
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
* use pull_request_target instead of pull_request
Signed-off-by: Pasta <pasta@dashboost.org>
* use pasta based action 0.1.1
Signed-off-by: Pasta <pasta@dashboost.org>
79f0a3f1f42e0421e60cf9a57f6c70c6be9221a1 Get more info about GUI-related issue on Linux (Hennadii Stepanov)
Pull request description:
There is bunch of combinations Linux Distro (Debian, Fedora, Ubuntu etc) + Desktop Environment (GNOME, KDE, Xfce etc) + Graphical Shell (Unity, GNOME Shell etc).
This PR adds related requests to the issue template. Providing such data will make GUI-related issue reviewing and reproducing easier.
Tree-SHA512: 9728d7826108b62a916c43523572d1da1b52b43a21b3d550a84225ff67951224e0b8a9394627f274d7c65383b3f526bcd12cc40eef9d7fec174c19d1abf333d8
faede70882b4fd54390f5205dbe1dbcf019195c8 doc: Add formatting to the good first issue template (MarcoFalke)
Pull request description:
Add minor formatting to the good first issue template so that it is easier to see with one glance what the required skills are.
Preview is here: https://github.com/MarcoFalke/bitcoin-core/issues/new/choose
ACKs for top commit:
fanquake:
ACK faede70882b4fd54390f5205dbe1dbcf019195c8
Tree-SHA512: 0b0fcd051166981455061442e69f42c9fa726eaa228856e57434e012f7224781f4f3f12c31ce0a7a322df9999e79a8fbe63bf800b7933bc52c7cdaed90f37598