ci: automate releases and refactor ci #1270
Conversation
|
The checks are failing because the |
|
@GeorgesStavracas could you please review this? |
| git config --global user.name "github-actions[bot]" | ||
| git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com" | ||
| git config --global --add safe.directory $GITHUB_WORKSPACE |
There was a problem hiding this comment.
Hm, here does this come from?
There was a problem hiding this comment.
The username and email are required to have the commit appear like it was made by the official github-actions bot (the same one that creates releases, as you can see here for example). AFAIK the email is not documented anywhere officially, I just found it on some random GitHub discussion page and it worked.
The safe.directory thing is needed because otherwise git is complaining about it and doesn't allow to add commits.
|
The whole mechanism to build the container is a bit meh. While working on something unrelated I had a look at it and created a mechanism that's closer to FDO/gnome gitlab: there is a tag and when the container with the tag doesn't exist, it will be build, all part of a push or pull request: swick@c208dc7 |
|
@swick it seems like your mechanism doesn't auto-update the dependencies though? From what I can see, the date tag is pinned to a specific value which has to be updated manually |
|
Yes, and that is on purpose. The idea here is that if someone works on a branch they might need to adjust the image for CI to pass. Having a cron job create the image means you'd have to first merge the workflow, wait or manually trigger it and then merge the rest. The changes in my branch makes it possible to just bump the tag in a commit of a new branch and CI will do "the right thing". |
| tests/*.log | ||
| test-*.log | ||
| installed-test-logs/ | ||
| builddir/meson-logs/testlog.txt |
There was a problem hiding this comment.
This is now _build/meson-logs/testlog.txt
|
Besides the image rebuild logic this MR LGTM. |
|
@swick the way I did CI image building more closely resembles how it worked before, where the image always had the latest dependencies I understand the benefits of your method, I just don't know whether the manual intervention needed to update the dependencies fits into the existing workflow. @GeorgesStavracas what do you think about this? |
|
Sure, the image always had the latest dependencies, but because it was always build it also means that it had exactly the image that one wanted on a specific branch. |
cc @GeorgesStavracas