Make packagist/composer require github artifact (instead of commit)

Workflow & Best Practices
1

Pe scurt:

  • se dă un pachet composer
  • codul are nevoie de ceva build pentru a fi utilizabil. Build-ul ăsta se realizează cu github actions, partea asta e ok
  • vreau ca packagist.org să ia artefactul ăla pentru deploy, nu un anumit commit.

Ce știu că se poate, dar NU vreau:

  • să fac utilizatorii să adauge URL-ul în composer.json. Vreau ca pentru cel care instalează pachetul, tot procesul ăsta să fie complet transparent. I.e. instalarea să se facă doar cu composer require iamntz/pachet
  • satis sau alte scamatorii private.

Am întrebat și aici, nu m-au ajutat comentariile.

2

RDDD[1] in action :sweat_smile:

După ce am pus aici, am încercat să pun cheia "dist" în composer.json. Packagist se pare că ține cont de treaba asta complet nedocumentată.

Yay :smiley:

  1. Rubber duck driven development ↩︎

3

Pana la urma e documentata, un pic.

4

Poți să-mi arăți și unde e documentată?

5

No, da care e “build” ala asa special? ca uitandu-ma pe sursa carbon-fields-urlpicker/release.yml at v3 · iamntz/carbon-fields-urlpicker · GitHub

nu vad nimic ce n-ar putea fi rezolvat cam asa:

  1. gitignore everything development
  2. gitattributes export-ignore (in loc de rsync ala ciudat)
  3. git-actions “npm build”, commit,
    3a. release
6

N-am zis că ar fi un build special ci doar se … întâmplă chestii care vreau să ajungă în packagist DAR să nu fie în repo.

Rsync ăla ciudat elimină fișiere inutile. Nu sunt sigur ce face alternativa cu gitattributes :confused: Poți da un exemplu concret?

Nu sunt sigur dacă flow-ul propus de tine e mai bun (dar nici nu sunt sigur că flow-ul meu e mai bun).

7

Ok, so:

toate fisierele alea comprezate (zip, tar.gz) de pe GitHub, nu sunt altceva decat rezultatul comenzii git archive dupa cum se poate vedea si in url-ul fisierului
long story, short Rundown of the Git Archive Command

Si composer si npm se folosesc de arhivele alea ca sa nu mai faca git clone etc
Un common practice, e sa te folosesti de fisierul .gitattributes si sa pui “export-ignore” la fisierele care nu le vrei in pachet. In genul la .gitignore dar pt “dist”

Sincer nu prea vad un motiv pentru care sa nu faci un commit cu fisierele alea js compilate (in afara de frumusete)

Eu ma gandesc la cazul asta:
Ca developer, fac un git clone la repo-ul tau, ca vreau sa vad/testez chestii, diferite versiuni.
Ti-as multumi enorm, daca as putea sa checkout diferite versiuni si sa nu mai pierd timp compiland js-urile

Si nu doar “lenea” de a mai compila, dar poate vreau sa testez build-ul tau cu build-ul meu, ca poate o versiune ciudata de node sau mai stiu eu ce, produce rezultate diferite

1 Like
8

Fix la acel repo mai primesc câte un PR din an în paște. Și îmi este mai simplu să aprob un PR (din web) când văd ce s-a schimbat vs un JS compilat care poate conține și chestii malițioase, deci trebuie să-i dau pull local → compilez → commit → push.

Uite aici, de exemplu, schimbarea propriu-zisă conține vreo zece caractere; le pot „evalua” în cap, pot decide instant dacă este sau nu bun de aprobat. Problema e că mai conține și js-ul compilat, iar pe ăla nu îl mai pot „evalua” în cap :slight_smile: Fix readme and blank field value by josecoelhomelo · Pull Request #16 · iamntz/carbon-fields-urlpicker · GitHub

9

da “Boss”, dar stii ca poti sa ai fisierul ala compilat in .gitignore dar in acelasi timp sa faci TU sau github-actions un git add -f ignoredfile.js

Si pur si simplu ii zici lu Ionica sa isi update PR-ul si sa scoata js compilat

.gitignore ala nu e un ignore per-se, e o protectie anti aia care fac git add .

1 Like
10

Si inca un caz pt .gitattributes ar fi

Vreau sa fac un fork, pt ca din varii motive e mai usor.

  • fac fork
  • modific fisierele
  • npm build
  • git commit && push
  • modific composer.json sa foloseasca fork meu.

done
Nu trebuie sa imi setez si eu github actions si alte nebunii

11

composer: A Composer repository is a packages.json file served via the network (HTTP, FTP, SSH), that contains a list of composer.json objects with additional dist and/or source information.

 {
            "type": "package",
            "package": {
                "name": "smarty/smarty",
                "version": "3.1.7",
                "dist": {
                    "url": "https://www.smarty.net/files/Smarty-3.1.7.zip",
                    "type": "zip"
                },
                "source": {
                    "url": "https://smarty-php.googlecode.com/svn/",
                    "type": "svn",
                    "reference": "tags/Smarty_3_1_7/distribution/"
                }
            }
        }
12

Dacă te referi la partea asta: vezi că aia documentează altceva, nicidecum modul în care packagist interpretează composer.json.