Skip to content
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

Merged
merged 3 commits into from
Nov 14, 2023

Conversation

Ansuel
Copy link
Member

@Ansuel Ansuel commented Nov 14, 2023

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

Screenshot 2023-11-14 144440


@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.

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"
Copy link
Member

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?

Copy link
Member Author

@Ansuel Ansuel Nov 14, 2023

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?

Copy link
Member

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.

Copy link
Member

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)

Copy link
Member

@ynezz ynezz Nov 14, 2023

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)

Copy link
Member Author

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 :(

Copy link
Member Author

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

@Ansuel
Copy link
Member Author

Ansuel commented Nov 14, 2023

@ynezz any clue about the production tag for deploy? And about extending the hash to 12 char

@ynezz
Copy link
Member

ynezz commented Nov 14, 2023

@ynezz any clue about the production tag for deploy?

Can you provide more details about this? What is wrong now and what would be improved, how it would like after this change?

And about extending the hash to 12 char

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 :)

@Ansuel
Copy link
Member Author

Ansuel commented Nov 14, 2023

Can you provide more details about this? What is wrong now and what would be improved, how it would like after this change?

We would have these additional feature

image

image

@ynezz
Copy link
Member

ynezz commented Nov 14, 2023

We would have these additional feature

Ok, this is going to change what exactly? We've currently following in the Ansible config:

docker_image_buildmaster: 'ghcr.io/openwrt/buildbot/buildmaster-v3.8.0:v8@sha256:7bb21dda47e8e0ead3fd4a64e57d782d950c309e81655d1684c38e87bf2aa0e9'
docker_image_buildworker: 'ghcr.io/openwrt/buildbot/buildworker-v3.8.0:v9@sha256:e3f4d838dfe65906af93923a7902e56e2ed861b8debffcca3d0db89c580905ae'

@Ansuel
Copy link
Member Author

Ansuel commented Nov 14, 2023

@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

@ynezz
Copy link
Member

ynezz commented Nov 14, 2023

Reading https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment

It seems like production might be misleading, maybe release would fit better here? We don't do any deployments (yet).

@Ansuel
Copy link
Member Author

Ansuel commented Nov 14, 2023

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?)

@ynezz ynezz merged commit e07ee3e into openwrt:master Nov 14, 2023
5 checks passed
@Ansuel
Copy link
Member Author

Ansuel commented Nov 14, 2023

Nooo wanted to replace the value :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants