Thread: how to manage Cirrus on personal repository
I have a private repository on GitHub where I park PostgreSQL development work. I also have Cirrus activated on that repository, to build those branches, using the existing Cirrus configuration. Now under the new system of limited credits that started in September, this blew through the credits about half-way through the month. Does anyone have an idea how to manage this better? Is there maybe a way to globally set "only trigger manually", or could we make one? I suppose one way to deal with this is to make a second repository and only activate Cirrus on that one, and push there on demand. Any ideas?
> On 29 Sep 2023, at 11:13, Peter Eisentraut <peter@eisentraut.org> wrote: > Does anyone have an idea how to manage this better? Is there maybe a way to globally set "only trigger manually", or couldwe make one? On my personal repo I only build via doing pull-requests, such that I can control when and what is built and rate-limit myself that way. Using the Github CLI client it's quite easy to script "push-and-build". Not sure if it's better, it's just what I got used to from doing personal CI on Github before we had Cirrus support in the tree. -- Daniel Gustafsson
Hi,
On Fri, 29 Sept 2023 at 13:24, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> I have a private repository on GitHub where I park PostgreSQL
> development work. I also have Cirrus activated on that repository, to
> build those branches, using the existing Cirrus configuration.
>
> Now under the new system of limited credits that started in September,
> this blew through the credits about half-way through the month.
>
> Does anyone have an idea how to manage this better? Is there maybe a
> way to globally set "only trigger manually", or could we make one?
You can create another repository / branch with only a .cirrus.yml
file which will only have the 'trigger_type: manual' line. Then, you
can go to your private repository's settings on Cirrus CI and set
REPO_CI_CONFIG_GIT_URL=github.com/{user}/{repository}/.cirrus.yml@{branch}
environment variable. This will write contents of the newly created
.cirrus.yml file to your private repository's .cirrus.yml
configuration while running the CI. You can look at the .cirrus.star
file for more information. I just tested this on a public repository
and it worked but I am not sure if something is different for private
repositories. I hope these help.
Regards,
Nazir Bilal Yavuz
Microsoft
On Fri, Sep 29, 2023 at 7:11 AM Daniel Gustafsson <daniel@yesql.se> wrote: > > > On 29 Sep 2023, at 11:13, Peter Eisentraut <peter@eisentraut.org> wrote: > > > Does anyone have an idea how to manage this better? Is there maybe a way to globally set "only trigger manually", orcould we make one? > > On my personal repo I only build via doing pull-requests, such that I can > control when and what is built and rate-limit myself that way. Using the > Github CLI client it's quite easy to script "push-and-build". Not sure if it's > better, it's just what I got used to from doing personal CI on Github before we > had Cirrus support in the tree. It is not a global configuration solution, but I just add an empty ci-os-only: tag to my commit messages so it doesn't trigger CI. I'm sure this is not what you are looking for, though - Melanie
Hi, On 2023-09-29 11:13:24 +0200, Peter Eisentraut wrote: > I have a private repository on GitHub where I park PostgreSQL development > work. I also have Cirrus activated on that repository, to build those > branches, using the existing Cirrus configuration. > > Now under the new system of limited credits that started in September, this > blew through the credits about half-way through the month. :( > Does anyone have an idea how to manage this better? Is there maybe a way to > globally set "only trigger manually", or could we make one? One way is to configure to run under a custom compute account. If we get credits from google, that might be realistic to provide to many hackers, it's not that expensive to do. Another thing is to work on our tests - we apparently waste *tremendous* amounts of time due to tap tests forking psql over and over. We definitely can provide a way to configure on a repo level which tests run automatically. I think that would be useful not just for turning things manual, but also the opposite, enabling tests that we don't want everybody to run to automatically run as part of cfbot. E.g. running mingw tests during cfbot while keeping it manual for everyone else. Maybe we should have two environment variables, which can be overwritten set on a repository level, one to make manual tasks run by default, and one the other way? > I suppose one way to deal with this is to make a second repository and only > activate Cirrus on that one, and push there on demand. You already can control which platforms are run via commit messages, fwiw. By adding, e.g.: ci-os-only: linux, macos Greetings, Andres Freund
On Sat, Sep 30, 2023 at 3:35 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: > On Fri, 29 Sept 2023 at 13:24, Peter Eisentraut <peter@eisentraut.org> wrote: > > I have a private repository on GitHub where I park PostgreSQL > > development work. I also have Cirrus activated on that repository, to > > build those branches, using the existing Cirrus configuration. > > > > Now under the new system of limited credits that started in September, > > this blew through the credits about half-way through the month. [Replying to wrong person because I never saw Peter's original email, something must be jammed in the intertubes...] It's annoying, but on the bright side... if you're making it halfway through the month, I think that means there's a chance you'd have enough credit if we can depessimise the known problems with TAP query execution[1], and there are some more obviously stupid things too (sleep/poll for replication progress where PostgreSQL should offer an event-based wait-for-replay, running all the tests when only docs changed, running the regression tests fewer times, ...). [1] https://www.postgresql.org/message-id/flat/CA%2BhUKGJoEO33K%3DZynsH%3DxkiEyfBMZjOoqBK%2BgouBdTGW2-woig%40mail.gmail.com
On 9/29/23 18:02, Thomas Munro wrote: > On Sat, Sep 30, 2023 at 3:35 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: >> On Fri, 29 Sept 2023 at 13:24, Peter Eisentraut <peter@eisentraut.org> wrote: >>> I have a private repository on GitHub where I park PostgreSQL >>> development work. I also have Cirrus activated on that repository, to >>> build those branches, using the existing Cirrus configuration. >>> >>> Now under the new system of limited credits that started in September, >>> this blew through the credits about half-way through the month. > > [Replying to wrong person because I never saw Peter's original email, > something must be jammed in the intertubes...] > > It's annoying, but on the bright side... if you're making it halfway > through the month, I think that means there's a chance you'd have > enough credit if we can depessimise the known problems with TAP query > execution[1], and there are some more obviously stupid things too > (sleep/poll for replication progress where PostgreSQL should offer an > event-based wait-for-replay, running all the tests when only docs > changed, running the regression tests fewer times, ...). I also have Cirrus setup for my cloned Postgres repo and it is annoying that it will run CI whenever I push up new commits that I pulled from git.p.o. My strategy for this (on other projects) is to require branches that need CI to end in -ci. Since I use multiple CI services, I further allow -cic (Cirrus), -cig (Github Actions), etc. PRs are also included. That way, nothing runs through CI unless I want it to. Here's an example of how this works on Cirrus: # Build the branch if it is a pull request, or ends in -ci/-cic (-cic targets only Cirrus CI) only_if: $CIRRUS_PR != '' || $CIRRUS_BRANCH =~ '.*-ci$' || $CIRRUS_BRANCH =~ '.*-cic$' Regards, -David