-
Notifications
You must be signed in to change notification settings - Fork 14
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: generic improvement and cleanup of workflow #20
Conversation
Move git short sha length to ENV to make it easier to configure in the future if needed. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Generalize container test step by using include feature of matrix strategy and defining additional values for container command test and config verification. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Split container push related steps to separate jobs and add deploy tag. This is to better organize the workflow and drop additional checks for single steps moving them to the single job. Also we use a feature of github to better track changes deployed to our buildbot. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
- worker | ||
include: | ||
- container_flavor: master | ||
container_verify_string: "buildmaster configured in /master" |
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.
Wouldn't this approach get hairy once we would like to add more checks/tests?
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.
Mhhh yes...
I wonder if the test will be done all on logs tho...
If we will check that then we might consider adding all the check on a shell script and just run it here.
But you are right if the intention is to add additional stuff then I think the current way of keep the master and worker split is the only way...
MAYBE I can split the get log part/generalize the command to run the container?
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.
Well its actually very lame testing, but better then no testing.
In the long term I planned to look into labgrid's DockerStrategy and use that for more advanced QA, the similar approach could be then re-used for SDK/ImageBuilder/rootfs container testing in the openwrt/docker repository etc.
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.
Perhaps we could keep it as it is proposed now and improve later (tm)
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.
buildbot.errors.PluginDBError: Requirements are not satisfied for buildbot.www:base: The 'zope-interface>=5' distribution was not found and is required by Twisted
Murphy's law? :P https://github.com/openwrt/buildbot/actions/runs/6867270540/job/18678271015#step:5:51
(BTW its not caused by this PR)
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.
Yes I notice the same while testing this pr. Thing it's there from a lot :(
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.
About Murphy's law... I had to rerun the test as for some reason the github instance lost connection ahahaha
@ynezz any clue about the |
Can you provide more details about this? What is wrong now and what would be improved, how it would like after this change?
Fine with me, but FYI its really not needed, I don't expect this project to grow into kernel scale of commits to hit any collisions :) |
Ok, this is going to change what exactly? We've currently following in the Ansible config:
|
@ynezz won't change anything, just extra bonus (the thing is enabled by adding the environment value in the job) Honestly it's just a cosmetic change |
It seems like |
we can even use builbot if we really want. But yes release seems better... My idea of deploy is that this is actually a deploy as buildbot will use the new version. (or this assumption is wrong?) |
Nooo wanted to replace the value :( |
Improve and refactor some part of the workflow to better organize it and use github deploy feature.
The final result on a running push is the following
@ynezz my only question is what we should use as tag... Is "production" ok? We can use whatever we want... Also buildbot.
Aside from this, it's just a cleanup and improvement.
Also also... Should we change the short version for git to 12? Using 8 has been deprecated... No idea if it does cause problems.