~andrewrk


#24 Handle .git postfix on source URLs when doing source replacement 4 days ago

Comment by ~andrewrk on ~sircmpwn/dispatch.sr.ht

The issue is that this is a poor user experience:

  • fill in a valid looking git URL into the sources field
  • enable the pull request dispatch
  • things appear to be working, but find out several weeks later that the pull request -> build dispatch hook is actually building master branch and not pull requests

Must I have a solution in mind for this to be an open todo item?

#24 Handle .git postfix on source URLs when doing source replacement 4 days ago

Comment by ~andrewrk on ~sircmpwn/dispatch.sr.ht

Thanks - that fixed it. I'll leave this issue open with the feature request that if this mistake is made, the CI fails with an error message telling how to fix the yml

#24 Handle .git postfix on source URLs when doing source replacement 4 days ago

Ticket created by ~andrewrk on ~sircmpwn/dispatch.sr.ht

See downstream issue for details: https://github.com/ziglang/zig/issues/1960

#35 Add more base images 11 days ago

Comment by ~andrewrk on ~sircmpwn/builds.sr.ht

Zig project is about to have a use case for OpenBSD builds: https://github.com/ziglang/zig/pull/1921

#58 Implement build caches a month ago

Comment by ~andrewrk on ~sircmpwn/builds.sr.ht

What's the sr.ht way to say I am also interested in this feature ?

#164 feature request: configurable path to build.yml 2 months ago

Comment by ~andrewrk on ~sircmpwn/builds.sr.ht

No problem. I couldn't find the bug tracker for dispatch.sr.ht so I put it in the sr.ht tracker.

#151 feature request: configurable path to build.yml 2 months ago

Ticket created by ~andrewrk on ~sircmpwn/sr.ht

Moved from https://todo.sr.ht/~sircmpwn/builds.sr.ht/164

Here's my use case: I have another CI dependency on Azure Pipelines in order to get Windows support. I've put the files in a subdirectory to keep my repo organized. I'd like to put the sr.ht build file in a subdirectory as well, like this:

ci
├── azure
│   ├── linux_script
│   ├── macos_script
│   ├── pipelines.yml
│   ├── update_download_page
│   ├── windows_install
│   ├── windows_script.bat
│   └── windows_upload
└── srht
    └── build.yml

While testing, this would be submitted via dispatch.sr.ht, but potentially in the future would be submitted via git.sr.ht.

#164 feature request: configurable path to build.yml 2 months ago

Ticket created by ~andrewrk on ~sircmpwn/builds.sr.ht

Here's my use case: I have another CI dependency on Azure Pipelines in order to get Windows support. I've put the files in a subdirectory to keep my repo organized. I'd like to put the sr.ht build file in a subdirectory as well, like this:

ci
├── azure
│   ├── linux_script
│   ├── macos_script
│   ├── pipelines.yml
│   ├── update_download_page
│   ├── windows_install
│   ├── windows_script.bat
│   └── windows_upload
└── srht
    └── build.yml

#131 Improve internal site switching 2 months ago

Comment by ~andrewrk on ~sircmpwn/todo.sr.ht

As an example, right this second I am looking at a ticket for ~sircmpwn/todo.sr.ht. And I want to go look at the mailing lists for todo.sr.ht. As far as I'm aware there is no way to navigate from this page, to that page, without manually editing the URL. Another problem is that if I was unaware that there was a mailing list, there is no way to discover it, from here.

#131 Improve internal site switching 2 months ago

Comment by ~andrewrk on ~sircmpwn/todo.sr.ht

I agree that cross-service linking in its current form is a problem, although I'm not sure I understand your suggested solution.

I think the crux of the matter comes down to this: if someone is used to looking at GitHub or GitLab, for example, there are services all available in the menu laid out in tab form that correspond to sr.ht services. For example, Code, Issues, Pull Requests, Projects, Wiki, Settings. These links are all project-local links.

Now, looking at sr.ht, there are corresponding links at the top, laid out in tabs as expected, however these are not project-local links - they are global links to sr.ht services. This is confusing for the uninitiated.

Even for the initiated, however, I would argue it is far more common, when looking at any given service for a project, to want to see the other services available for that project, than it is to want to explore more sr.ht services independent from any project. I would expect the prominence of the UI buttons to reflect this.