The next PR I am about to make (improve-ci branch), which is a lot more substantial than this one, currently has a failing test that I can't fix without making changes to the most recent commit on master, the one that added the ci tests in the first place. and they have to exist on master before that PR is made, as it can't be done all at once. Reason being the test checks out the current master branch and then runs regression tests on the the new commits and because one of the things the next PR does is test multiple nixpkgs (20.03, 20,09, and nixos-unstable) it's like playing whack a mole. one of those pick two and only two of three situations. This changes it enough to get around the problem and the other branch makes everything a lot better. I don't even think most of the code in this one survives after the merge. rip. (I see that double pretty table)
(I did not enjoy dealing with all of the merge conflicts I had during the rebase that hopefully makes all of this go smoothly. I'm still fixing things almost a day later)
anyway so rather than force push to master to make the changes I want I decided to be nice and make a PR. :smile: this branch should apply and pass tests and then after it is merged the main feature branch (improve-ci) I've been working on should as well. It was designed to apply after this one so it should be a clean patch and pass tests. That's the plan anyway. Should be able to stick it. Worst case I force push to master. :rofl:
The next PR I am about to make (improve-ci branch), which is a lot more substantial than this one, currently has a failing test that I can't fix without making changes to the most recent commit on master, the one that added the ci tests in the first place. and they have to exist on master before that PR is made, as it can't be done all at once. Reason being the test checks out the current master branch and then runs regression tests on the the new commits and because one of the things the next PR does is test multiple nixpkgs (20.03, 20,09, and nixos-unstable) it's like playing whack a mole. one of those pick two and only two of three situations. This changes it enough to get around the problem and the other branch makes everything a lot better. I don't even think most of the code in this one survives after the merge. rip. (I see that double pretty table)
(I did not enjoy dealing with all of the merge conflicts I had during the rebase that hopefully makes all of this go smoothly. I'm still fixing things almost a day later)
anyway so rather than force push to master to make the changes I want I decided to be nice and make a PR. :smile: this branch should apply and pass tests and then after it is merged the main feature branch (improve-ci) I've been working on should as well. It was designed to apply after this one so it should be a clean patch and pass tests. That's the plan anyway. Should be able to stick it. Worst case I force push to master. :rofl: