Submit without specifying files #1044
Conversation
|
This PR seems to assume the current directory is an exercise directory. As a student, I build and submit my projects from the workspace root, not from individual exercises. I should be able to do |
|
This PR does assume that. I sympathize with your use case, but I think allowing directories should probably be discussed better outside this PR. The idea here is to allow to submit files without specifying anything. Allowing directories should be another feature and a separate discussion as the CLI currently explicitly disallows them. |
|
I don’t think it is “my use case” as much as it is convenience and common sense. If the point of this PR is to improve user experience, adding an additional step of going in the directory is anything but. If the goal of this PR is to reduce user error due to missing files, that is not achieved either because they may submit from a wrong working directory. |
Like in my comment above, the CLI has been carefully designed and has evolved over a long period of time. Therefore, new changes should be discussed before being implemented and carefully considered by the Exercism team.
This is a personal opinion and not something that has any data to back it up with. Exercism documents and guides are all written from the viewpoint of the CLI being used from within the exercise's directory. This is also how the vast majority of users use the CLI. I also don't like the "common sense" remark, which suggests that arguing otherwise implies a lack of common sense. Note that we're not against any changes, but we do feel that changes to such a widely-used tool as the CLI should be carefully thought out and considered by the Exercism team. You clearly feel strongly about being able to submit a directory, so what you should do is open an issue where we can discuss its merits.
I disagree with this statement. For the vast majority of the users, this PR will be extremely helpful. It will make using the CLI more ergonomic, greatly reduces the chance of students submitting the wrong files (this will only happen if they manually submit files) whilst still allowing for the current behavior.
This is a rude statement and not constructive in any way. I'll kindly refer you to our Code of Conduct for guidance on how we expect our community members to interact with each other. Side note: I think the feature this PR supports are possibly the number one most request feature. |
There was a problem hiding this comment.
Thank you so much for doing this! This is probably our number one most wanted CLI feature :)
I don't know any Go though, so maybe @ekingery could take a look?
|
@andrerfcsantos Thanks for doing this! |
|
Merged! Thanks so much! Next step: building a new release. @ekingery remind me what the steps are? |
There is RELEASE.md. The previous release was the first that was signed, with @ekingery's key. So I guess Eric has to be the person who releases, if we want to keep signing with the same key. The process of verifying the signature is:
I don't know whether the CLI is packaged anywhere that expects releases to be signed with that key. At least the AUR package doesn't check the key. If it did, it would have this line: For later, should we consider having a dedicated key for signing CLI releases, which perhaps could live in this repo as a secret? See GoReleaser docs on signing. A release would also be nice to include commits like: Currently: $ exercism version
exercism version 3.0.13
$ exercism --help | head -n1
A command-line interface for the v2 redesign of Exercism. |
Yes, the generated packages should not rely on my (or any) signature at this point, so changing the signing key for the next release will be fine. I agree, a dedicated signing key (or keys) would be best - I just signed it because it was faster to get done so it's probably also fine to have whoever is building the release sign it. Ideally we would continue to automate the release process by building and signing using Github Actions: https://goreleaser.com/ci/actions/?h=sign#signing |
|
@ekingery I think getting the release process automated is quite important. Would you be interested in working on that? |
I will spend a little time poking around - shouldn't be too much work to at least make some progress, although I can't promise anything due to a pretty tight schedule I'm working with these days. I am happy to work with anyone else who volunteers as well - anyone with some knowledge or interest in learning github actions and simple scripting tools would be able to contribute meaningfully. |
|
@ekingery I'm happy to help with the GitHub Actions part, as I've worked with it quite a lot. Others can join too of course. Maybe someone from @exercism/github-actions? |
|
@ErikSchierboom I can help. I'm no expert in Github Actions, but I can learn :) Let me know what you need. |
|
Great! We have a RELEASE.md document that details how a release can be built using Here is the page with details on integrating GoReleaser with GitHub actions: https://goreleaser.com/ci/actions/ Their example runs the script when a new tag is published, and I think that is a nice way to handle this. |
|
@ErikSchierboom Will take a closer look at it later. However, at a quick glance, I see we'll need |
|
The The other, we'll need to define ourselves. For the other two values, we'll need to set them manually I guess. @iHiD could you check whether there are any secrets defined for the GPG private key and/or passphrase? And if not, add them? |
|
Cool! Reading the release instructions more carefully, I realize we also need the credentials for snapcraft to publish the snap. This post mentions that it's possible to create a credentials file for snap. Putting this file as a secret will also be useful for CI to perform |
|
Ah neat. I'll check that out. |
|
@ekingery I'd also be happy to help work on the automation bit. Meanwhile... how hard would it be to do a manual release? I'd really like to get this change shipped so people can use it. I'd be happy to do the release if there's a way to do it without your keys, so long as I can holler if I get stuck working through RELEASE.md, since it's been a few years since I've touched this repo. |
@kytrinyx, cutting a release manually would be a great way to prep for the automation. It should be much easier than it used to be 🤞. As you have probably seen it does require the new tooling as described in the RELEASE.md file. Happy to help with any issues you run into or questions you have! I am on the exercism slack, or we can hash things out here or via email - whatever works best for you. |
|
Awesome, thank you @ekingery. I'll take a stab at this over the weekend. |
|
@kytrinyx when you eventually succeed, can you give me a ping with the version number so I can update the vscode extension to use the automated submission from that version forward? |
|
Okay, I've cut a release but was unable to publish to snapchat (linux) and homebrew (mac). People should still be able to install the old version and then use the @SleeplessByte the new version is v3.1.0 |
|
@kytrinyx Can confirm upgrading with $ exercism version
exercism version 3.0.13
$ exercism upgrade
$ exercism version
exercism version 3.1.0 |
|
@andrerfcsantos That's excellent news! Thank you. |
|
Great to see a new release! I checked verifying the signature with the new key: $ cd /tmp || exit
$ curl -sSfLO 'https://github.com/exercism/cli/releases/download/v3.1.0/exercism-3.1.0-linux-x86_64.tar.gz'
$ curl -sSfLO 'https://github.com/exercism/cli/releases/download/v3.1.0/exercism_checksums.txt'
$ curl -sSfLO 'https://github.com/exercism/cli/releases/download/v3.1.0/exercism_checksums.txt.sig'
$ gpg --keyserver keys.openpgp.org --verbose --recv-key 816A8B8E703E53110F1D0FBBE8761A9E46258B62
gpg: data source: http://keys.openpgp.org:11371
gpg: armor header: Comment: 816A 8B8E 703E 5311 0F1D 0FBB E876 1A9E 4625 8B62
gpg: armor header: Comment: Katrina Owen <[email protected]>
gpg: pub rsa4096/E8761A9E46258B62 2020-10-17 Katrina Owen <[email protected]>
gpg: using pgp trust model
gpg: key E8761A9E46258B62: public key "Katrina Owen <[email protected]>" imported
gpg: Total number processed: 1
gpg: imported: 1
$ gpg --verify --verbose exercism_checksums.txt.sig
gpg: assuming signed data in 'exercism_checksums.txt'
gpg: Signature made Tue 04 Oct 2022 11:29:59 CEST
gpg: using RSA key 816A8B8E703E53110F1D0FBBE8761A9E46258B62
gpg: using pgp trust model
gpg: Good signature from "Katrina Owen <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 816A 8B8E 703E 5311 0F1D 0FBB E876 1A9E 4625 8B62
gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096
$ sha256sum --check --ignore-missing exercism_checksums.txt
exercism-3.1.0-linux-x86_64.tar.gz: OKI know at least the AUR package doesn't need to update the key, since it didn't check the signature anyway: https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=exercism |
Fixes #991
Adds the possibility of submitting without specifying files, with the "algorithm" specified in #991 (comment)
Other than the tests in the PR, I also tried to submit solutions using this version of the program, including messing up the exercise directory and everything went as expected :)