Running `git describe` in local setup correctly identifies the tag available on the tag. But `docker buildx` via actions does not identify it without `--tags` param.
Reference Issue: https://github.com/ElementsProject/lightning/issues/7626
Changelog-Fixed: Docker image created via github actions correctly reads the tag available on the HEAD.
- Temporarily adding `rc` tag trigger for testing `Build and push multi-platform docker images` action flow before the final release.
- Added some variable inputs for testing like repo, platforms, etc.
- Added more logs for future debugging.
Documents which are deleted from lightning schema were still listed on readme server.
This script was adding or updating the list but delete action was missing.
Changelog-None.
This PR is adding github action for auto Docker releases. This will streamline Docker image builds & releases for enhanced efficiency, reliability, and consistency in managing Docker-based deployments.
The build & release event will be triggered:
- On any new tag creation without rc suffix.
- Manually for testing purposes.
Changelog-None.
Issue: rpc documentation on the readme server is not being updated.
It is an extension of PR #7326 to fix runtime error from github actions.
Changelog-None.
Issue: rpc documentation on the readme server is not being updated.
Updating the path from `doc/**.md` to `doc/schemas/lightning-*.json` for triggering the action because all `doc/*.7.md` files are fully generated by the `tools/fromschema.py` now.
Added manual trigger event for readme's documentation update.
Changelog-None.
Now that our rpc documenation is generated from schema, we need to build
the docs before trying to update the rdme contents. The goal is to fix
the following issue with the rdme-rpc-sync workflow:
Run python .github/scripts/sync-rpc-cmds.py
lightning-addgossip lightning-addgossip.7.md
Traceback (most recent call last):
File .github/scripts/sync-rpc-cmds.py, line 92, in <module>
main()
File .github/scripts/sync-rpc-cmds.py, line 82, in main
with open(doc/ + file) as f:
FileNotFoundError: [Errno 2] No such file or directory: 'doc/lightning-addgossip.7.md'
This workflow has never had a particularly good signal-to-noise ratio,
and disabling it saves us a couple of GH Actions cycles, with only
minor reduction in test reach. We should rather rethink this and use
the installation instructions to write Dockerfiles for each described
architecture, and then have the CI test-build those Dockerfiles. That
would also cover the docs during testing, rather than having yet another
place where the instructions can bitrot away.
Changelog-None No user-visible change.
Tacking the fuzz testing onto the PR testing not a good idea. It
causes completely unrelated tests to fail, and doesn't guarantee it
will find newly introduced ones. Running daily is likely better.
Changelog-None No user visible change
Turns out that if we publish from PRs we may end up with versioning
collisions, causing errors. This publishes only from `master` where we
have a linearizable history, and should therefore get unique versions.
Changelog-None
We are tracking the flakiness of tests [here][1], so no need to suffer
through fail-looping CI while trying to fix a PR or get it merged.
Changelog-None
[1]: http://35.239.136.52:3170/run
We used to run the publication on each PR, which could cause conflicts
due to the naming convention being based on the commit history length,
and multiple PRs potentially hitting the same name.
Adding a `workflow_dispatch` trigger allows us to still test the
workflow in PRs but only do so manually (when we're watching anyway).
Changelog-None
Code using `CI_SERVER` was added recently to track something. It
attempts to short-cut if `CI_SERVER` is not set, but on gitlab it
is set to `yes`. https://docs.gitlab.com/ee/ci/variables/
Instead use `CI_SERVER_URL`, maybe that is what is intended?
We were accidentally testing against `bitcoind` rather than
`elementsd` which meant we believed everything was find, when in
reality some tests broke. By only installing the required daemon we
ensure that such a mixup causes a CI failure.
