#publish via a hex api key?

1 messages · Page 1 of 1 (latest)

tiny elbow
#

Does gleam publish (or perhaps what it uses) require the hex username and password as the only supported method of authentication, or can it support hex's api keys?

fierce yew
#

Not supported currently but a PR would be accepted

#

Open an issue if you have some ideas for designs

#

Or a need

tiny elbow
#

No idea if hex's api even allows it! Doesn't look like rebar suggests a way to do it with the api key only either..

fierce yew
#

It does!

tiny elbow
#

Sounds like it'd be a good idea to suggest then, I might put it in later, 2AM and just finished setting it up to name-squat for the week or two it'll take to make my thing -- but I am happy to see the html img embeds rendering on the hexdocs page https://hexdocs.pm/collatz/index.html

collatz · v0.0.1

Functions Related to the Collatz/Syracuse/3n+1 Problem

fierce yew
#

Squatting is against the Hex terms of service fyi, make sure you start publishing stuff soon!

tiny elbow
#

It's tongue-in-cheek only lol

tiny elbow
tiny elbow
# fierce yew Not supported currently but a PR would be accepted

Opened the issue and started on the branch for it; wanted to build locally and test before PR'ing it, but running into a whole bunch of can't find crate when make build'ing (with latest stable rust) (and the uploaded artifact from the ci workflow appears to want to be used on a later ubuntu version, not working without glibc versions that appear to be missing that it's expecting, so might take a while to figure them out).

fierce yew
#

How strange

#

I wonder what that might be

#

Our release builds don't depend on glibc, so not sure what you mean there

tiny elbow
#

If I try to run the version uploaded by the ci workflow on my wsl ubuntu 20.04 I get

gleam: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by gleam)
gleam: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by gleam)
gleam: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by gleam)
#

Not sure why

fierce yew
#

That's for the CI integration tests to use, I didn't even know you could download it

#

20.04 is pretty old so I imagine CI is using a newer glibc

#

Just ignore it, there's nothing useful you can do with that version from CI 👍

tiny elbow
#

Good to know -- and yea, you can scroll to the end of the workflow run and manually download the actions/upload-artifact artifacts; the workflows, including release, using ubuntu-latest so they're building to 22.04, and the release version works on 20.04, so doubt there'd be a point in trying to figure out why I can't get the CI one to work! That being said, is there somewhere I should be adding a test for the change to publish command? I couldn't find anywhere else that the HEXPM_* env var names existed for example to be used in setting for a test.

fierce yew
#

We don't have any integration tests for publishing etc currently, it'll be manually tested

#

If you want to work out a way to do that then that's cool

tiny elbow
#

Cool so atm I will need to figure out how to get cargo build to work I guess!

fierce yew
#

Could you share the error message from cargo build please? 🙏

tiny elbow
#

It wasn't the same every time, it would progressively get through about 30 to 50 different dependencies out of 300 and then stumble on one of them and print about 20 or so errors about references to external crates being errors for the crate not found reason. It's different every time though which one it picks and the order it compiles them in, so not sure how helpful any individual stacktrace will be.

fierce yew
#

Just any of the errors would be good

tiny elbow
#

The last one was

   Compiling unicode-normalization v0.1.23
error[E0463]: can't find crate for `tinyvec_macros` which `tinyvec` depends on
  --> /home/skenvy/.cargo/registry/src/index.crates.io-6f17d22bba15001f/unicode-normalization-0.1.23/src/lib.rs:53:1
   |
53 | extern crate tinyvec;
   | ^^^^^^^^^^^^^^^^^^^^^ can't find crate
fierce yew
#

What's the error above that one?

#

Or the most recent error that isn't "can't find crate"

tiny elbow
#

Took 13 runs of make build -- it would simply appear that it's just rust not compiling them in order, because it will eventually just come back around to recompile ones it broke on earlier after compiling their dependencies in a subsequent run, but these are all the errors.

📎 errors
fierce yew
#

Wow something is really wrong with your Rust install

#

I wonder what it is

tiny elbow
#

Node 18.18.2, Erlang 25, Rust 1.77 (cargo 1.77.0 (3fe68eabf 2024-02-29)) -- Shouldn't be anything wrong with the rust install, even updated it and cargo clean and it's still breaking on the same stuff, will have to figure it out tomorrow.

fierce yew
#

Node and Erlang are not used in building the compiler so it's something on the Rust side

tiny elbow
#

I've got it working (turns out the problem was some interaction with windows, I can run it fine if I move it inside wsl's filesystem) -- and I can gleam publish with my hex api key -- but there's an issue that it prompts for unset environment variables, and this introduces a choice between api key and username / password, so how would be best to not require all env vars it's reading are explicitly set or trigger a prompt e.g. my use case (and not breaking it for people that do set the username and password and don't expect it to prompt them) is to run it in cicd, e.g. can't let it prompt.

#

some sort of --ci flag or equivalent to say "don't prompt" would be the simplest

#

But I'm not sure where the cli's flags are being determined.

tiny elbow
#

But managed to publish and retire a package to test it with both the api key and the username and password, so it works.

stuck hazel
#

Did this get merged?
I'm, trying to get hold of a hex API key so we can use it in CI

fierce yew
#

I think Hex dropped support for that recently

#

It's a v big security risk and Hex has been focusing a lot on security lately due to the new laws around supply chain attacks and the increase in attacks

#

I believe write actions require MFA now

#

If you do use API keys in GitHub make sure you set up GitHub CodeQL scanning for your workflows as it's quite easy to get a code injection vulnerability with actions config files

stuck hazel
#

I'm not looking for a key to publish, sorry I should have been clearer. The problem I am trying to solve is we are hitting some rate limits when pulling packages in ci

fierce yew
#

Ah right, sorry. Nope that feature doesn't exist yet.
How many packages are you pulling in?

stuck hazel