flake: disable CI for packages

[zowoq]

@adisbladis @jian-lin

Unfortunately the size of the jobset and types of builds has been a problem, thousands of small, cheap builds is basically the opposite of all of the other hydra jobs.

If there are specific packages that would benefit from being built and cached they can be added back to hydraJobs, even a few hundred would be fine, just not thousands.

[jian-lin]

Removing all elisp packages from CI is a bit unfortunate. However, I support this decision since it causes trouble for the infra team.

If there are specific packages that would benefit from being built and cached they can be added back to hydraJobs

Currently we use CI results to find broken builds when bumping all elisp packages in Nixpkgs. Here is an example. We can build all elisp packages locally to find broken builds after this PR.

I would like another maintainer of this repo to take a look before I merge this.

[zowoq]

Currently we use CI results to find broken builds when bumping all elisp packages in Nixpkgs.

I didn't know that it was used for this. Does this involve the stable and unstable sets from this repo or just unstable? I wouldn't mind running a eval manually once every couple of weeks of reduced jobset, e.g. only unstable on x86_64-linux.

[jian-lin]

Does this involve the stable and unstable sets from this repo or just unstable?

Only packages of the unstable channel is used for this. And yes, currently we only care about x86_64-linux.

I wouldn't mind running a eval manually once every couple of weeks of reduced jobset

That would be great! Currently we do those bumps each time a staging-next cycle starts. So yeah, once every couple of weeks.

Building all elisp packages locally would take about 30 minutes. However, building them in CI would give reviewers of those bumps some useful links.

[zowoq]

What about these emacs variants, is it fine to only build them every couple of weeks or would you want to keep building them continuously?

emacs-overlay/flake.nix

Lines 73 to 81 in 045f679

	emacsen = {
	inherit (pkgs) emacs-unstable emacs-unstable-nox;
	inherit (pkgs) emacs-unstable-pgtk;
	inherit (pkgs) emacs-git emacs-git-nox;
	inherit (pkgs) emacs-git-pgtk;
	inherit (pkgs) emacs-igc emacs-igc-pgtk;
	inherit (pkgs) emacs-lsp;
	inherit (pkgs) commercial-emacs;
	};

[jian-lin]

We want to keep building emacs variants continuously. There are known users of some of them and only 5 of them change frequently.

[zowoq]

We can't do both in the same flake on hydra, currently it hardcodes #hydraJobs and falls back to #checks.

Would need to separate the variants and the packages into different attributes and either make the hardcoded attributes configurable in hydra or move the emacs variants to a different CI (buildbot supports a scheduled build without PR checks, similar to hydra but it can use a different attribute).

[jian-lin]

Thanks for the info. Building Emacs variants on buildbot and elisp packages on hydra (with manual triggers) sound great!.

I am not familiar with CI settings for both hydra and buildbot. I can allocate some time to figure this out in 1 or 2 weeks.

I notice that currently hydra only build Emacs variants so I guess this is not urgent. Please correct me if I am wrong.

[zowoq]

I notice that currently hydra only build Emacs variants so I guess this is not urgent.

Separate attributes and buildbot/hydra changes isn't urgent but currently hydra is building this branch so will need to keep rebasing the PR until it is merged.

I've opened #512 for the separating the attributes for buildbot but I'll look at making hydra configurable in the next few days, I don't think it'll be too complicated to resolved.

[zowoq]

@jian-lin Can you merge this please?

[jian-lin]

@zowoq Sure. What is the path forward after this PR?

[zowoq]

Let me know when you want to bump the nixpkgs elisp packages and I'll apply the hydra patch and trigger an eval of #512.

[jian-lin]

@zowoq Here is the last bump NixOS/nixpkgs#435408. I think we will do another bump in a week or two.