-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: automate releases and refactor ci #1270
base: main
Are you sure you want to change the base?
Conversation
The checks are failing because the |
@GeorgesStavracas could you please review this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I completely dropped the ball on this. Had a couple of comments, but I want to play with this branch in my fork a little, see how it goes, etc
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, here does this come from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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