> I agree committing builds.txt to the source git repository is pretty unorthodox. Perhaps it’s a security malpractice to keep source and build artifacts derived from that source code;
If having the text available in source was necessary, I would use a git hook. That would address the security implications of a bot account. In this scenario, I see no need to have the list in source. > do you know if there’s a programatic way to manually upload things without relying on actions/upload-pages-artifact actions/upload-pages-artifact is implemented on top of actions/upload-artifact (https://github.com/actions/upload-artifact), which in turn uses this js lib from GitHub: https://github.com/actions/toolkit/tree/main/packages/artifact. So in theory you could write a js script to upload things manually. Keep in mind that uploading the artifact is only one step of the process. You also need to deploy the page with actions/deploy-pages, which as far as I can tell, doesn't have its own API out of actions yet. I suspect you could reverse engineer something in bash from the source, but I feel that it will be pretty painful. > If there isn’t that seems like a pretty big vendor lock-in (we’re already pretty locked in to GitHub but I like to think it’s pretty portable... maybe?) GitLab has its own equivalent: https://docs.gitlab.com/ee/user/project/pages/ which is a lot easier to use since they are far more open company. GitLab Pages is also supported on self-hosted instances: https://docs.gitlab.com/ee/administration/pages/source.html which gives us an extra degree of control. If at all we were to leave GitHub this could be very easily ported to GitLab. I think GitLab is a good enough solution in case things go south (I don't see us moving to cgit any time soon). However, porting previous previous artifacts is non-trivial, so we may loose our history unless we sit down and download every version from GH. -- bp On Saturday 7 September 2024 at 00:31:00 UTC+5:30 woj...@wojtekmach.pl wrote: > I agree committing builds.txt to the source git repository is pretty > unorthodox. Perhaps it’s a security malpractice to keep source and build > artifacts derived from that source code; in that case, please disregard > this. I thought it’s straightforward enough as opposed to relying on Hex S3 > bucket for this and while at it solve > https://github.com/erlef/setup-beam/issues/260. I did not know about > https://github.com/actions/upload-pages-artifact, this is pretty > interesting! I couldn’t find much documentation about it besides the action > itself and to me it feels a bit like implementation detail of GitHub Pages. > For example, do you know if there’s a programatic way to manually upload > things without relying on actions/upload-pages-artifact, you know, `curl -X > POST ...` or `gh release upload … $ref $file`? If there isn’t that seems > like a pretty big vendor lock-in (we’re already pretty locked in to GitHub > but I like to think it’s pretty portable... maybe?) > > On 6 Sep 2024, at 17:50, Benjamin Philip <benjamin....@gmail.com> wrote: > > *Reposting on googlegroups since I'm unsure if my reply was received when > replied via email.* > > *> *My proposal is to automate this on GitHub Actions, similar to > https://github.com/livebook-dev/livebook/blob/v0.14.0/.github/workflows/assets.yml#L52:L57. > > (It is a bit annoying though because we can't easily make sure only one > GitHub job of this type runs at a time AND there could be other commits > happening on main in the meantime. The best I could come up with is: > https://github.com/wojtekmach/otp_builds/blob/2209f680a2f8d8e50c73509790bac565ef65b1d3/.github/workflows/update_builds.yml#L30:L67 > .) > > Why commit builds.txt to main at all? An alternate solution would be to > host it on GitHub Pages <https://pages.github.com/>, maybe at > https://hexpm.github.io/bob? `builds.txt` could be deployed to > https://hexpm.github.io/bob/main/builds.txt as well as > https://hexpm.github.io/bob/<ref>/builds.txt on push. Deploying a website > to multiple urls is made trivial with the deploy-pages action > <https://github.com/actions/deploy-pages>. > > This would have a number of advantages over your proposed solution: > > 1. Concurrent runs are not a concern - each commit is deployed to its own > url for reference, and the latest of the actions is deployed to the > bob/main url. > 2. We do not have bot accounts committing to main, convoluting the git > history. A bot account may also have security problems > 3. A workflow like this would be far easier to maintain since similar > workflows are fairly common (so docs, guides etc. may exist). Plus GitHub > does most of the heavy lifting. > > A potential concern is if the artifact for the site will expire. Looking > through the upload-pages-artifact action > <https://github.com/actions/upload-pages-artifact> docs, there are no > expiries as of right now. However, we are at risk of GitHub deciding to > expire old artifacts in the future. > > -- bp > > On Friday 6 September 2024 at 19:31:22 UTC+5:30 woj...@wojtekmach.pl > wrote: > >> For tools like asdf, setup-beam, and similar it is very useful to get a >> list of all Elixir releases (included per-OTP builds). Doing this through >> GitHub REST API can be slightly complicated due to dealing with JSON, >> pagination, and rate-limiting. >> >> Hex/Bob keeps a https://builds.hex.pm/builds/elixir/builds.txt which has >> none of these problems. >> >> Since a few release ago, Elixir build are available on Elixir GitHub >> release. And so to keep similar things together, I'd like to propose adding >> something like (or exactly) such builds.txt file in the GitHub repository. >> This way we could, although there are no such plans at the moment, >> deprecate Hex/Bob-maintainted Elixir builds. >> >> With this proposal, the way to get all Elixir builds could be simply: >> >> $ curl -fL https://github.com/hexpm/bob/raw/main/builds.txt >> >> Since Elixir 1.14, the builds in GitHub releases follow the pattern >> elixir-otp-VSN.zip. Prior to that it was Precompiled.zip, compiled against >> the oldest supported OTP version for that Elixir release ( >> https://hexdocs.pm/elixir/compatibility-and-deprecations.html#between-elixir-and-erlang-otp). >> >> I'd still add them to the builds file for informational purposes but I'm OK >> with not doing that either. >> >> We could just adopt the Hex builds.txt format, here's an example: >> >> v1.17.2 47abe2d107e654ccede845356773bcf6e11ef7cb 2024-07-06T21:18:45Z >> c1a0860b805ef4925ca9e97ecf9f84b3d3fc62e6a48a91c1cbe6344c3b02400b >> v1.17.2-otp-25 47abe2d107e654ccede845356773bcf6e11ef7cb >> 2024-07-06T21:18:45Z >> c1a0860b805ef4925ca9e97ecf9f84b3d3fc62e6a48a91c1cbe6344c3b02400b >> v1.17.2-otp-26 47abe2d107e654ccede845356773bcf6e11ef7cb >> 2024-07-06T21:20:26Z >> a2e32bf61a8dd1354ce41bed891cee72e02cbf5b4532fa190416547f422a97b4 >> v1.17.2-otp-27 47abe2d107e654ccede845356773bcf6e11ef7cb >> 2024-07-06T21:23:11Z >> 4e32e8761bd73916feaa24eaa98d86b1d929039e38e778b37553b0330f75b9f6 >> >> This way existing tools can easily switch to it. Since it'd be a new URL >> though, we have a chance to potentially improve it. Here's one idea which I >> believe will make it super clear what's what: >> >> <ref_name>[-otp-VSN] <date> git:<ref> sha256:<sha> >> >> e.g.: >> >> v1.17.2-otp-27 2024-07-06T21:23:11Z >> git:47abe2d107e654ccede845356773bcf6e11ef7cb >> sha256:4e32e8761bd73916feaa24eaa98d86b1d929039e38e778b37553b0330f75b9f6 >> >> (See https://github.com/hexpm/bob/pull/188#discussion_r1701912589) >> >> My proposal is to automate this on GitHub Actions, similar to >> https://github.com/livebook-dev/livebook/blob/v0.14.0/.github/workflows/assets.yml#L52:L57. >> >> (It is a bit annoying though because we can't easily make sure only one >> GitHub job of this type runs at a time AND there could be other commits >> happening on main in the meantime. The best I could come up with is: >> https://github.com/wojtekmach/otp_builds/blob/2209f680a2f8d8e50c73509790bac565ef65b1d3/.github/workflows/update_builds.yml#L30:L67 >> .) >> > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-co...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/cd4e0dbb-d338-445c-b4fd-8bb2b4d55520n%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/cd4e0dbb-d338-445c-b4fd-8bb2b4d55520n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/ae6177cd-fd46-4eb5-8fe9-ebb817db0f65n%40googlegroups.com.
